Zend+Framework+Issue+Tracker - DOC

Document Sample
Zend+Framework+Issue+Tracker - DOC Powered By Docstoc
					[ZF-11216] support for IMAP IDLE Created: 23/Mar/11   Updated: 23/Mar/11
Status:               Open
Project:              Zend Framework
Component/s:          Zend_Mail
Affects Version/s:    None
Fix Version/s:        None

Type:                 New Feature        Priority:             Major
Reporter:             Dominik Gehl       Assignee:             Dolf Schimmel (Freeaqingme)
Resolution:           Unresolved         Votes:                0
Remaining Estimate: Not Specified
Time Spent:           Not Specified
Original Estimate:    Not Specified


Description
add support for IMAP IDLE
[ZF-11178] Validate_Hostname fails with Transport_Smtp::helo() when
using "localhost" Created: 16/Mar/11 Updated: 16/Mar/11
Status:                Open
Project:               Zend Framework
Component/s:           Zend_Mail, Zend_Validate
Affects Version/s:     None
Fix Version/s:         None

Type:                  Bug                                Priority:               Major
Reporter:              Gabriel Schuster                   Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:            Unresolved                         Votes:                  1
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified


Description
When sending mail through SMTP, Transport_Smtp sets "localhost" as default HELO.
It seems that Validate_Hostname does not like that as it is not a "real" DNS hostname.
At least I have an entry in my translation log that says that the message "'%value%' does not match the expected
structure for a DNS hostname" could not be found in locale "en".
Because of this log entry I assume that the validator failed and threw the corresponding error - otherwise the
Translator would never be called to translate that message, would it?
The email, btw, is sent without any problems.

I'm not sure if this is a bug in Validate_Hostname or if the default HELO for Transport_Smtp should be changed to
something else like "127.0.0.1".
When setting the IP there is no error logged, but it's not only when it's using the default - even when setting
"localhost" explicitly in the options the error again occurs, so I think it's a bug in Validate_Hostname.

Tested on SVN checkout from 15.03.2011.
A discussion (German) regarding this issue can be found here: http://www.zfforum.de/showthread.php?t=7856
[ZF-11081] Wrong item numbering with Zend_Paginator over Zend_Mail
Created: 16/Feb/11 Updated: 18/Feb/11
Status:                  Open
Project:                 Zend Framework
Component/s:             Zend_Mail, Zend_Mail_Storage, Zend_Paginator
Affects Version/s:       1.11.3
Fix Version/s:           None

Type:                    Bug                                Priority:              Major
Reporter:                Helmuth Gronewold                  Assignee:              Dolf Schimmel (Freeaqingme)
Resolution:              Unresolved                         Votes:                 0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
Hi!

I'm trying to use pagination in my email listing.
There are 52 items in my mailbox. On the first page it numbers from 1 to 10, but on the second page the listing starts
with 10 again and goes up to 19. 20 to 29 on the following page and so on. Everything is fine without pagination. The
items are correctly displayed with the numbers 1 to 52.

This is the code I'm using:

MaillistController.php
$mail = new Zend_Mail_Storage_Imap(array('host'     => 'host',
                                         'user'     => 'user',
                                         'password' => 'pass',
                                       'ssl' => 'TLS'));

$this->view->number_messages = count($mail);

$paginator = new Zend_Paginator(new Zend_Paginator_Adapter_Iterator($mail));
$paginator->setCurrentPageNumber((int) $this->getRequest()-
>getParam('page'));
$this->view->mail = $paginator;
list.phtml
<div>
<?php foreach ($this->mail as $messageNum => $message): ?>
        <p><?=$messageNum?>: <?=$message->subject ?></p>
<?php endforeach; ?>
</div>
<hr/>
<?php echo $this->paginationControl($this->mail, 'Sliding',
'my_pagination_control.phtml'); ?>


Comments
Comment by Kai Uwe [ 18/Feb/11 12:53 AM ]
Components changed. It relates to Zend_Paginator and not Zend_Navigation.
[ZF-11045] Zend_Mail_Transport_Abstract: To, Cc, Bcc are splitted with
EOL, but shouldn't Created: 07/Feb/11 Updated: 07/Feb/11
Status:                  Open
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       None
Fix Version/s:           None

Type:                    Bug                                Priority:               Critical
Reporter:                Martin Keckeis                     Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:              Unresolved                         Votes:                  0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
On line 196 in Zend_Mail_Transport_Abstract, the header content get imploded.

$value = implode(',' . $this->EOL . ' ', $content);

This cause my server to write the "to", "cc", "bcc" sometimes in the "from" section and other crazy things.

Releated to http://tools.ietf.org/html/rfc5322:

           to = "To:" address-list CRLF
           cc = "Cc:" address-list CRLF
           bcc = "Bcc:" [address-list / CFWS] CRLF

Where stands nowhere, that each address needs a new line, only at the end of complete address-list.

So right should be (like it works also for me)

$value = implode(',' . ' ', $content);
[ZF-11022] Setting resources.mail.transport.register = true causes an
extra email to be sent to a bogus address. Created: 02/Feb/11 Updated: 03/Feb/11
Status:                   Open
Project:                  Zend Framework
Component/s:              Zend_Application_Resource, Zend_Mail
Affects Version/s:        1.11.3
Fix Version/s:            None

Type:                     Bug                                     Priority:                  Critical
Reporter:                 jsnod                                   Assignee:                  Dolf Schimmel (Freeaqingme)
Resolution:               Unresolved                              Votes:                     0
Remaining Estimate: Not Specified
Time Spent:               Not Specified
Original Estimate:        Not Specified

File Attachments:             Zend_Application_Resource_Mail.diff
Issue Links:              Related
                          is related to      ZF-9011      Unable to set additional parameters f...              Resolved

Description
When using Zend_Mail_Transport_Sendmail via Zend_Application_Resouce_Mail and setting
resources.mail.transport.register = true, I noticed a superfluous email being sent to a non-existent address in my
mail logs:

Jan 30 04:30:14 myserver postfix/local[15519]: A97C84F52B:
to=<1@mydomain.com>, orig_to=<1>, relay=local,
delay=0.08, delays=0.03/0.02/0/0.03, dsn=5.1.1, status=bounced (unknown user:
"1")
Jan 30 04:30:14 myserver postfix/local[15523]: B4DF24F547:
to=<1@mydomain.com>, orig_to=<1>, relay=local,
delay=0.02, delays=0/0.01/0/0.01, dsn=5.1.1, status=bounced (unknown user:
"1")

The problem is that the 'register' value gets passed into Zend_Mail_Transport_Sendmail->__construct() as part of the
$parameters array. For some reason, this causes an additional mail to be sent to 1@mydomain.com. This can be
very costly when sending large amounts of email – Postfix is having to work double for every email sent.

Another side-effect of this bug is that it breaks the fix added by , so you are unable to pass in an actual $parameters
option to change sender envelope. Doing so results in the sending of yet another email to a bad address that looks
like it comes from the specified envelope value, eg: -tcustomenvelope@mydomain.com. So in this case, ZF is
attempting to send three emails when it should only send one!

I have a patch to fix this and will attach, but I'm not sure if this is the best way to fix it.

For reference, here is my application.ini

resources.mail.transport.type                                   = Zend_Mail_Transport_Sendmail
resources.mail.transport.register                               = true
resources.mail.defaultFrom.email                                = from@mydomain.com
resources.mail.defaultFrom.name                                         = "My Name"
resources.mail.defaultReplyTo.email                             = from@mydomain.com
resources.mail.defaultReplyTo.name                          = "My Name"
resources.mail.transport.envelope                           = "-f from@mydomain.com"


Comments
Comment by jsnod [ 02/Feb/11 09:40 PM ]
Can't for the life of me find out how to upload a patch as an attachment, so here it is:

Index: Zend/Application/Resource/Mail.php
===================================================================
--- Zend/Application/Resource/Mail.php (revision 23688)
+++ Zend/Application/Resource/Mail.php (working copy)
@@ -124,6 +124,7 @@
         }

              unset($options['type']);
+             unset($options['register']);

              switch($transportName) {
                  case 'Zend_Mail_Transport_Smtp':

Comment by Benoît Durand [ 02/Feb/11 10:01 PM ]
To send a patch, you must sign the CLA      before.
Comment by jsnod [ 03/Feb/11 02:21 PM ]
patch attached
Comment by jsnod [ 03/Feb/11 06:25 PM ]
Whoops, ignore that last attachment, I accidentally uploaded the wrong one. This is the proper patch.
[ZF-10970] Zend_Mail does not create multipart/alternative messages
with plain+HTML where the HTML has embedded images. Created: 20/Jan/11
Updated: 09/Mar/11
Status:                     Open
Project:                    Zend Framework
Component/s:                Zend_Mail
Affects Version/s:          1.11.2
Fix Version/s:              None

Type:                       Patch                              Priority:             Major
Reporter:                   Colin Guthrie                      Assignee:             Dolf Schimmel (Freeaqingme)
Resolution:                 Unresolved                         Votes:                0
Remaining Estimate: Not Specified
Time Spent:                 Not Specified
Original Estimate:          Not Specified

File Attachments:              zend-mail-multipart-related-html.patch

Description
Hi,

When converting a system I currently use to one based on Zend_Mail I discovered that it was not possible to create a
message that had two primary parts (plain text and HTML) where the HTML part itself was really a multipart/related
section containing the HTML and all the images it uses. My existing system did this, so I decided to "make it so" with
Zend_Mail.

I have patched things in a way that is fully backwards compatible with the current usage (I've not actually run the unit
tests but if none of the new APIs are called the old behaviour is preserved so I'm quite confident they will pass!).

It can be used in the following way:

           <?php

           $transport = new Zend_Mail_Transport_Smtp('localhost');
           Zend_Mail::setDefaultTransport($transport);

           $mail = new Zend_Mail('utf-8');
           $mail->setFrom("apache@localhost.localdomain", "Jonathon Livingston Seagull");
           $mail->addTo('user@localhost');
           $mail->setSubject('Test Email');

           $mail->setBodyText('Hello world.');

           $url = dirname(_FILE_).'/world.jpg';
           $cid = md5($url);
           $jpg = file_get_contents($url);
           $mail->setBodyHtml('<html><body><p>Hello world</p><img src="cid:'.$cid.'" /></body></html>');
           $mail->createHtmlRelatedAttachment($jpg, $cid, 'image/jpeg', Zend_Mime::DISPOSITION_INLINE,
           Zend_Mime::ENCODING_BASE64, 'world.jpg');

           $mail->send();
It should deal gracefully with HTML+Related Images (i.e. no plain text component) by forcing the type of the mail itself
to multipart/related.

It seems that someone (Ivan) basically asked this same question on the comments page for Zend_Mail just the other
day so it seems I'm not alone!
http://framework.zend.com/manual/en/zend.mail.attachments.html




Comments
Comment by Colin Guthrie [ 20/Jan/11 06:37 AM ]
Patch to implement this new feature.
Comment by Colin Guthrie [ 20/Jan/11 07:21 AM ]
I noticed a typo in my original code after a refactor... count() was still included after pushing it out to a variable rather
than checking the array directly. Very minor change.
Comment by Colin Guthrie [ 09/Mar/11 04:21 AM ]

Ping? Some kind of feedback would be nice
[ZF-10864] Zend_Mail with SMTP Authentication Created: 23/Dec/10                                     Updated: 05/Jan/11
Status:                 Open
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      None
Fix Version/s:          None

Type:                   Bug                                   Priority:               Major
Reporter:               Habeeb Raja                           Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:             Unresolved                            Votes:                  1
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
Hi All,
I'm using Zend_Mail with SMTP authentication. while running that application it returns an error.(i.e, Application
Error.). If I use the same code without SMTP authentication, its working fine. What i need to do...

Thanks...




Comments
Comment by Ryan Mauger [ 23/Dec/10 02:05 AM ]
Habeeb,

Could you supply code to reproduce your issue, currently there is not enough info to know if this is a support request,
or an actual bug with the framework.

If this is a support request, then this issue should be closed, and the question directed to either the fw-general mailing
list, of #zftalk on IRC.
Comment by Ramon Henrique Ornelas [ 23/Dec/10 02:38 AM ]
Assigned component and the mantainer.
Comment by Craig Carnell [ 05/Jan/11 04:09 AM ]
I am using the Zend Framework with Magento 1.4.2.0.

The standard getMail function in Magento doesn't support SMTP so I have replaced with the code below. It was
working in the past, but now I am getting an exception.

I need to use SMTP as the mail server is another machine.

Code below:

public function getMail()
{
if (is_null($this->_mail)) { $my_smtp_host = Mage::getStoreConfig('system/smtp/host'); $my_smtp_port =
Mage::getStoreConfig('system/smtp/port'); $config = array( //'ssl' => 'ssl', //optional 'port' => $my_smtp_port, //optional
- default 25 'auth' => 'login', 'username' => 'xxx', 'password' => 'xxx' ); $transport = new
Zend_Mail_Transport_Smtp('xxx', $config); Zend_Mail::setDefaultTransport($transport); $this->_mail = new
Zend_Mail('utf-8'); }
return $this->_mail;
}

Stack trace below:

2010-12-13T15:07:24+00:00 ERR (3):
exception 'Zend_Mail_Protocol_Exception' with message 'Operation not permitted' in
/usr/home/xxx/domains/xxx.co.uk/public_html/lib/Zend/Mail/Protocol/Abstract.php:254
Stack trace:
#0 /usr/home/xxx/domains/xxx.co.uk/public_html/lib/Zend/Mail/Protocol/Smtp.php(167):
Zend_Mail_Protocol_Abstract->_connect('tcp://mail.xxx...')
#1 /usr/home/xxx/domains/xxx.co.uk/public_html/lib/Zend/Mail/Transport/Smtp.php(199): Zend_Mail_Protocol_Smtp-
>connect()
#2 /usr/home/xxx/domains/xxx.co.uk/public_html/lib/Zend/Mail/Transport/Abstract.php(348):
Zend_Mail_Transport_Smtp->_sendMail()
#3 /usr/home/xxx/domains/xxx.co.uk/public_html/lib/Zend/Mail.php(1178): Zend_Mail_Transport_Abstract-
>send(Object(Zend_Mail))
#4 /usr/home/xxx/domains/xxx.co.uk/public_html/app/code/core/Mage/Core/Model/Email/Template.php(409):
Zend_Mail->send()
#5 /usr/home/xxx/domains/xxx.co.uk/public_html/app/code/core/Mage/Core/Model/Email/Template.php(462):
Mage_Core_Model_Email_Template->send('orders@xxx...', NULL, Array)
#6 /usr/home/xxx/domains/xxx.co.uk/public_html/app/code/core/Mage/Contacts/controllers/IndexController.php(104):
Mage_Core_Model_Email_Template->sendTransactional('contacts_email_...', 'support', 'orders@xxx...', NULL, Array)
#7 /usr/home/xxx/domains/xxx.co.uk/public_html/app/code/core/Mage/Core/Controller/Varien/Action.php(418):
Mage_Contacts_IndexController->postAction()
#8
/usr/home/xxx/domains/xxx.co.uk/public_html/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(253):
Mage_Core_Controller_Varien_Action->dispatch('post')
#9 /usr/home/xxx/domains/xxx.co.uk/public_html/app/code/core/Mage/Core/Controller/Varien/Front.php(176):
Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#10 /usr/home/xxx/domains/xxx.co.uk/public_html/app/code/core/Mage/Core/Model/App.php(304):
Mage_Core_Controller_Varien_Front->dispatch()
#11 /usr/home/xxx/domains/xxx.co.uk/public_html/app/Mage.php(596): Mage_Core_Model_App->run(Array)
#12 /usr/home/xxx/domains/xxx.co.uk/public_html/index.php(80): Mage::run('', 'store')
#13 {main}
[ZF-10853] Add unit tests to Zend_Mail_Protocol_Smtp for ZF2 Created:
19/Dec/10 Updated: 19/Dec/10
Status:                Open
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     None
Fix Version/s:         Next Major Release

Type:                  Task                              Priority:            Major
Reporter:              Marc Hodgins                      Assignee:            Marc Hodgins
Resolution:            Unresolved                        Votes:               0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified

Issue Links:           Related
                       is related to   ZF-10741   Zend_Mail_Protocol_Smtp needs unit tests   Resolved

Description
Need to implement unit tests (see ) for Zend_Mail_Protocol_Smtp in ZF2.
[ZF-10844] PHPUnit 3.5 code is being used on the test
Zend_Mail_FileTransportTest Created: 17/Dec/10 Updated: 19/Dec/10 Resolved: 17/Dec/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.11.1
Fix Version/s:           1.11.2

Type:                    Unit Tests: Problem                 Priority:             Major
Reporter:                Jeremy Postlethwaite                Assignee:             Jeremy Postlethwaite
Resolution:              Fixed                               Votes:                0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Issue Links:             Related
                         is related to       ZF-10849   PHPUnit showing deprecated warning on...          Open

Description
The following line of code is required in:

PHPUnit/Framework/SyntheticError.php

This is in PHPUnit 3.5, not 3.4




Comments
Comment by Jeremy Postlethwaite [ 17/Dec/10 04:29 PM ]
Removed PHPUnit 3.5 code
[ZF-10807] Dot character is duplicated when in 73rd position of plain text
content Created: 10/Dec/10 Updated: 18/Dec/10
Status:                  Open
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.11.1
Fix Version/s:           None

Type:                    Bug                                 Priority:               Major
Reporter:                Aigars Gedroics                     Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:              Unresolved                          Votes:                  0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
The dot character gets duplicated when sending mail with the dot character in the 73rd position (in reality in the
72*N+1 position, N>0).

The code to reproduce:

<?php

require_once('Zend/Mail.php');
$mail = new Zend_Mail();
$mail->addTo('test@test.com');
$mail->setFrom('test@test.com');
$txt = str_repeat('X', 72);
$mail->setBodyText($txt . '.' . 'END');
$mail->send();


Comments
Comment by Adam Lundrigan [ 17/Dec/10 05:44 PM ]
Tried it on my server (ZF 1.11.1) with this code:

$mail = new Zend_Mail();
$txt = str_repeat('X', 72);
$mail->setFrom('adam@localhost', 'Adam');
$mail->addTo('adam@localhost');
$mail->setBodyText($txt . '.' . 'END');
$mail->send();

And received this in the email body:

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.END

Which is the expected behavior (72 Xs, a dot, then 'END').
Comment by Dolf Schimmel (Freeaqingme) [ 18/Dec/10 08:41 AM ]
Do I understand correctly that this issue can be closed?
Comment by Adam Lundrigan [ 18/Dec/10 08:58 AM ]
I believe so. The code posted by the reporter has the expected behavior, so unless they can provide more
information the issue is closed.
[ZF-10792] encode comma in from/to/cc display name Created: 08/Dec/10                                 Updated:
08/Dec/10
Status:                Open
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     1.11.1
Fix Version/s:         None

Type:                  Improvement                        Priority:               Trivial
Reporter:              Christoph Roensch                  Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:            Unresolved                         Votes:                  0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified


Description
The Zend_Mail methods from(), addTo() and addCc() take a name to be displayed as second Parameter.
This parameter could corrupt the mail headers if it contains comma. Example:

$mail = new Zend_Mail();
$mail->setFrom('administrator@example.org');
$mail->setTo('doe@example.org', 'Doe, John');
$mail->send();

Now the mail would be send to 'doe@example.org' as well as 'doe@srv1.domain.local'.
If UTF-8 and Umlaute are involved the whole thing would pile up to something along '=?utf-
8?Q?d=C3=B6e@srv1.domain.local'

A work around would be to pass 'Doe%2C John'.
[ZF-10771] SMTP Login Enable support for "you are already
authenticated" Created: 03/Dec/10 Updated: 03/Dec/10
Status:                 Open
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.11.1
Fix Version/s:          None

Type:                   Improvement                        Priority:               Major
Reporter:               Wade Womersley                     Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:             Unresolved                         Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
Just found a bug in Zend_Mail_Protocol_Smtp_Auth_Login where if you are already authenticated the login fails
which causes emails to not be sent. The error is in the auth() function where after sending AUTH LOGIN it expects a
334 response code. Looking at the latest release that seems to have fixed Zend_Mail_Protocol_Abstract's issue of
not returning the full message. I decided the best solution would be to add the return code to the exception thrown by
_expect and catch it in Auth_Login.


Zend_Mail_Protocol_Abstract
throw new Zend_Mail_Protocol_Exception($errMsg); -> throw new Zend_Mail_Protocol_Exception($errMsg,
$cmd);


Zend_Mail_Protocol_Smtp_Auth_Login
public function auth()
    {
        // Ensure AUTH has not already been initiated.
        parent::auth();

            $this->_send('AUTH LOGIN');

            try
            {
            $response = $this->_expect(334);
        }
        catch(Zend_Mail_Protocol_Exception $ex)
        {
            if($ex->getCode() == 503 && strpos($ex->getMessage(),
'authenticated') !== false)
            {
                $this->_auth = true;
                return;
            }
        }
            $this->_send(base64_encode($this->_username));
            $this->_expect(334);
            $this->_send(base64_encode($this->_password));
            $this->_expect(235);
            $this->_auth = true;
      }


Comments
Comment by Marc Hodgins [ 03/Dec/10 04:00 AM ]
Hi Wade. Under what conditions would you be 'already authenticated' prior to calling $protocol->auth() ? As soon as
you call auth(), $this->_auth is set to true so that subsequent calls throw an exception.
Comment by Wade Womersley [ 03/Dec/10 04:05 AM ]
Easy, when your IP gets auto validated due to POP3 before SMTP. We have web servers in our office and PC's in
use by people too. All our data goes over 4 connections to the web: as a result of this, our IP addresses get auto
white listed on the SMTP server due to POP3 before SMTP so when Zend tries to connect from one of those IP's it
gets an "already authenticated" response.
Comment by Marc Hodgins [ 03/Dec/10 04:21 AM ]
What is the MTA (SMTP server) on the other end? The only mention in RFC4954           of 503 being a permissible
response to AUTH is:

          After an AUTH command has been successfully completed, no more
          AUTH commands may be issued in the same session. After a
          successful AUTH command completes, a server MUST reject any
          further AUTH commands with a 503 reply.

Even if the user is authenticated via POP3, it seems to me from this description that the first AUTH should be
accepted.

However, RFC or not, if this is standard behavior with POP3-before-SMTP then I agree that it should be supported in
the protocol adapter.
Comment by Wade Womersley [ 03/Dec/10 04:30 AM ]
It is indeed due to whitelisting, did a quick Google and found on this page , this:

                  If you see "503 you are already authenticated" message after entering the "auth login"
                   command, there are two possible reasons:
                   a) you already were authorized via POP3 authorization.
                   b) your IP is listed in white list, and you don't need to be authenticated in this case.

I know our server will temporarily whitelist if you authenticate via POP3 first but it also means some servers support
perma-whitelisting and therefore the current Login code would always fail if run behind that.
Comment by Marc Hodgins [ 03/Dec/10 05:26 PM ]
One concern with your proposed solution comes to mind. Consider this scenario:

    1.    You specify credentials for SMTP AUTH (i.e. username: foo)
    2.    You previously authenticated against POP3 (or whatever other mechanism) with user name "foo2"
    3.    The server rejects the AUTH, but your solution catches this exception
    4.    Your proposed solution handles the 503 by discarding the exception and flipping the auth flag to true in the
          protocol adapter

You asked to AUTH under "foo" but now you're auth'd under "foo2" and don't know it.

This could cause various unexpected behaviors. In some systems, the username you're AUTH'd against dictates
certain headers in outgoing mail (i.e. "From"). You might get confusing rejections trying to send from
"foo@mydomain.com" when unexpectedly auth'd under "foo2" because "foo@mydomain.com" is not a permitted
sender for foo2. Or, perhaps outgoing mail would be automatically set to be "from" that user.

Wouldn't it be better to handle this at the application level? i.e. try/catch the "already authenticated" exception and
then re-try without authentication?

If the SMTP error code (503) is made available in the exception then you could gracefully handle this on the
application side. which should be applied soon to trunk takes care of adding SMTP codes to the thrown exception so
it would give you this capability.
[ZF-10758] Support StartTLS for sending Mails via SMTP Created: 30/Nov/10
Updated: 30/Nov/10
Status:                  Open
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.11.0
Fix Version/s:           Next Major Release

Type:                    Improvement                         Priority:            Major
Reporter:                Simon Stücher                       Assignee:            Marc Hodgins
Resolution:              Unresolved                          Votes:               0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Issue Links:             Dependency
                         depends on      ZF-10741     Zend_Mail_Protocol_Smtp needs unit tests        Resolved

Description
Zend_Mail_Protocol_Smtp supports SSL and TLS, but not StartTLS (see contrstructor of Zend_Mail_Protocol_Smtp)

More information about StartTLS

          http://en.wikipedia.org/wiki/STARTTLS
          http://www.sendmail.org/~ca/email/starttls.html
          http://tools.ietf.org/html/rfc3207




Comments
Comment by Marc Hodgins [ 30/Nov/10 10:16 AM ]
My SMTP pipelining patch (ZF-8528) implements parsing of the EHLO keywords which would allow detection of
STARTTLS support. Awaiting application of to trunk and then I will refactor ZF-8528 out to split out a patch
specifically for EHLO keyword parsing. Then this one will be easier to implement.
[ZF-10741] Zend_Mail_Protocol_Smtp needs unit tests Created: 24/Nov/10                                        Updated:
19/Dec/10 Resolved: 19/Dec/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.11.0
Fix Version/s:           1.11.2

Type:                    Patch                               Priority:               Major
Reporter:                Marc Hodgins                        Assignee:               Marc Hodgins
Resolution:              Fixed                               Votes:                  0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

File Attachments:           ZF-10741.patch
Issue Links:             Dependency
                         is dependecy of      ZF-10758    Support StartTLS for sending Mails vi...           Open
                         is dependecy of      ZF-8528     Patch to add SMTP pipelining support ...           Open
                         Duplicate
                         is duplicated by     ZF-10249    Missing inclusion of SMTP status code...           Resolved
                         Related
                         is related to        ZF-10853    Add unit tests to Zend_Mail_Protocol_...           Open

Description
Hi Marc

You will push to git ZF2 to after close this issue?

Thanks advance




Comments
Comment by Marc Hodgins [ 24/Nov/10 09:50 AM ]
Patch adds unit tests to Zend_Mail_Protocol_Smtp, with a small refactoring of calls to PHP stream functions in
Zend_Mail_Protocol_Abstract to allow mocking of the protocol adapter for testing.
Comment by Marc Hodgins [ 06/Dec/10 01:28 PM ]
Applied to trunk in r23475, merged to release branch 1.11 in r23476. Leaving open for now to remind myself to add
these tests to ZF2.
Comment by Ramon Henrique Ornelas [ 18/Dec/10 02:32 AM ]
Hi Marc

You will push to git ZF2 to after close this issue? (because i think convenient create a task with Fix Version/s Next
Major Release).

Thanks advance
Comment by Marc Hodgins [ 19/Dec/10 04:46 PM ]
Marking as resolved. See ZF-10853 for implementation in ZF2.
[ZF-10729] Zend_Mail _formatAddress working incorrect Created: 23/Nov/10
Updated: 06/Dec/10 Resolved: 06/Dec/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.11.0
Fix Version/s:           Next Major Release

Type:                    Bug                                Priority:               Major
Reporter:                M Lehr                             Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:              Fixed                              Votes:                  0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
If you put a string with with a comma and special chars in the from name, the header get screwed up.

Unable to find source-code formatter for language: php. Available languages are: javascript, sql, xhtml, actionscript,
none, html, xml, java
$mail = new Zend_Mail();
$mail->setFrom('bernd@example.org', 'The rabbit, which is Bernd\'s best
frönd!');
$mailHeader = $mail->getHeaders();

echo $mailHeader['From'][0];

this will result in

Unable to find source-code formatter for language: php. Available languages are: javascript, sql, xhtml, actionscript,
none, html, xml, java
From: =?ISO-8859-1?Q?The_rabbit=2C_which_is_Bernd=27s_best_fr=F6nd=21?=
<bernd@example.org

the comma will not be encoded in quoted printable and therefor, the sendername will not be quoted so that the email
client could not recognize the whole sender name.




Comments
Comment by Kues Michael [ 27/Nov/10 05:22 AM ]
Tried to reproduce the behavior, but we could not reproduce it. The comma is ignored (meaning it is not converted to
a hex code in _encodeQuotedPrintable) which is the intended behavior. As stated by the Quoted-printable encoding
mechanism, all ASCII codes within the range 33 and 126 should be ignored. The comma falls within this range with
it's ASCII code 44.
Comment by M Lehr [ 01/Dec/10 08:52 AM ]
hi michael,

thanks for your reply.
yes the comma falls within the range - thats okay.

I think the problem is in Zend_Mail->_formatAddress.

Unable to find source-code formatter for language: php. Available languages are: javascript, sql, xhtml, actionscript,
none, html, xml, java
protected function _formatAddress($email, $name)
{
    if ($name === '' || $name === null || $name === $email) {
        return $email;
    } else {
        $encodedName = $this->_encodeHeader($name);
        if ($encodedName === $name &&
                 ((strpos($name, '@') !== false) || (strpos($name, ',') !==
false))) {
             $format = '"%s" <%s>';
        } else {
             $format = '%s <%s>';
        }
        return sprintf($format, $encodedName, $email);
    }
}

if $name is set, it will be encoded. So if there is a char which is not in the ASCII range between 33 and 126, this one
will be encoded ($encodedName = $this->_encodeHeader($name)

But then, the $name will only be double quoted when $encodedName === $name - but this will result in false if there
is a char with ASCII code outside of the range 33-126.
Comment by Dolf Schimmel (Freeaqingme) [ 04/Dec/10 02:04 PM ]
This would be the correct string, right?

From: =??Q?The=20rabbit,=20which=20is=20Bernd's=20best=20fr=C3=B6nd!?=
<bernd@example.org>
Comment by Dolf Schimmel (Freeaqingme) [ 06/Dec/10 03:34 AM ]
Assuming fixed in ZF2
[ZF-10710] Japanese subject garbled (mojibake) in Mac Mail, Yahoo Mail
for long strings Created: 18/Nov/10 Updated: 06/Dec/10
Status:                  Open
Project:                 Zend Framework
Component/s:             Zend_Mail, Zend_Mime
Affects Version/s:       1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.1, 1.7.2, 1.7.3, 1.7.4, 1.7.5, 1.7.6, 1.7.7, 1.7.8, 1.7.9, 1.8.0, 1.8.1,
                         1.8.2, 1.8.3, 1.8.4, 1.8.5, 1.9.0, 1.9.1, 1.9.2, 1.9.3, 1.9.4, 1.9.5, 1.9.6, 1.9.7, 1.9.8, 1.10.0,
                         1.10.1, 1.10.2, 1.10.3, 1.10.4, 1.10.5, 1.10.6, 1.10.7, 1.10.8, 1.11.0
Fix Version/s:           None

Type:                    Bug                                    Priority:                 Major
Reporter:                Michael Langford                       Assignee:                 Dolf Schimmel (Freeaqingme)
Resolution:              Unresolved                             Votes:                    0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
When using Zend_Mail with a multibyte subject over 72 characters long the _encodeHeader function calls
Zend_Mime::encodeBase64Header function which then calls the Zend_Mime::encodeBase64 function.

The Zend_Mime::encodeBase64 function performs a chunk_split on the base64 encoded subject. This results in an
unreadable garbled subject (known as mojibake in Japanese) in the Mac Mail application and in Yahoo Web Mail.

If the chunk_split from the is removed from the Zend_Mime::encodeBase64 function the subject is output as expected
in all Mail software.

This has occurred with UTF-8 emails.




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 04/Dec/10 02:13 PM ]
Can you please provide a few strings that currently fail for you? (that is, the input string, and the expected output
string)
Comment by Michael Langford [ 06/Dec/10 02:52 AM ]
The following in the subject, the to name, from name, cc name will cause the header to become corrupted.

テストテストテストテストテストテストテストテストテストテストテストテストテスト

This just says

testtesttesttesttesttesttesttesttesttesttesttesttesttest

Thanks
[ZF-10693] encoding issue Created: 17/Nov/10                  Updated: 04/Dec/10 Resolved: 04/Dec/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.10.8
Fix Version/s:          Next Major Release

Type:                   Bug                                Priority:               Major
Reporter:               Alexander                          Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:             Fixed                              Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
By default there is iso-8859-1 encoding at the constructor. And there is no way to change it except create another
class and inherit it from Mail class and set encoding at the new class.
So I believe the 'utf-8' encoding must be there by default.
it's very simple to fix.




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 04/Dec/10 01:49 PM ]
It would break BC either. I fixed it in ZF2 though.
[ZF-10651] Zend_Mail tests are running twice Created: 06/Nov/10                        Updated: 08/Nov/10
Resolved: 08/Nov/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.11.0
Fix Version/s:          1.11.1

Type:                   Patch                                 Priority:        Minor
Reporter:               Marc Hodgins                          Assignee:        Marc Hodgins
Resolution:             Fixed                                 Votes:           0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:           ZF-10651.patch

Description
Zend_Mail tests run twice in the test suite. Patch attached to correct this.




Comments
Comment by Matthew Weier O'Phinney [ 08/Nov/10 09:18 AM ]
Patch applied to trunk and 1.11 release branch.
[ZF-10567] Fatal error: Allowed memory size of 134217728 bytes
exhausted Created: 17/Oct/10 Updated: 17/Oct/10 Resolved: 17/Oct/10
Status:                    Closed
Project:                   Zend Framework
Component/s:               Zend_Mail
Affects Version/s:         1.10.7
Fix Version/s:             None

Type:                      Bug                                  Priority:                Minor
Reporter:                  Marvin D.                            Assignee:                Christoph, René Pardon
Resolution:                Not an Issue                         Votes:                   0
Remaining Estimate: Not Specified
Time Spent:                Not Specified
Original Estimate:         Not Specified


Description
I was following a tutorial from a book, I created a contact form with

          name
          email
          textarea
          captcha
           after i clicked the submit button i got this error

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 261904 bytes) in
C:\xampp\htdocs\zf\square\library\Zend\Mail.php on line 1174

then I tried increasing my memory limit.and restarted apache, then re-run my app,
and i still get the same error.. to be honest am not sure if this is a bug or it's just me or my
machine




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 17/Oct/10 08:44 AM ]
Could you please provide some (relevant) code that can be used to recreate this issue?
Comment by Marvin D. [ 17/Oct/10 08:52 AM ]
my application ini file http://www.pastie.org/1227818
my contact form library http://www.pastie.org/1227820
my contact controller code http://www.pastie.org/1227825
Comment by Christoph, René Pardon [ 17/Oct/10 02:08 PM ]
This is not a bug.
Your provided code has a lot of typos.

The problem can be solved by removing the $mail from send().

So:
$mail->send($mail);
should become:
$mail->send();

best regards
René
[ZF-10528] Zend Mail not setting return path Created: 07/Oct/10                              Updated: 25/Nov/10
Resolved: 25/Nov/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.10.4, 1.10.5, 1.10.6, 1.10.7, 1.10.8
Fix Version/s:          None

Type:                   Bug                                  Priority:               Minor
Reporter:               Robert mcCombe                       Assignee:               Marc Hodgins
Resolution:             Duplicate                            Votes:                  1
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Duplicate
                        duplicates      ZF-8988    Zend Mail Transport SMTP set sender e...                 Resolved

Description
I've been having problems setting the return path of each email sent out. When setting the from address this
overrides any changes to the return path. It seems the return path is still being set as on one of my mail servers one
email had two return path headers.

In the meantime I have reverted back to version 10.8.4 which doesn't seem to have the same problem.

I'm going to track back where the headers are being set and I'll release a patch if I can find the source of the problem.




Comments
Comment by Marc Hodgins [ 25/Nov/10 01:49 AM ]
I assume you are using the SMTP transport? If so this has been resolved in and the fix will appear in 1.11.1 release.
Please reopen if this remains an issue.
[ZF-10504] Zend_Mail_Protocol_Imap::examineOrSelect only returns a
subset of the actual server response Created: 29/Sep/10 Updated: 30/Sep/10
Status:                   Open
Project:                  Zend Framework
Component/s:              Zend_Mail
Affects Version/s:        1.10.8
Fix Version/s:            None

Type:                     Bug                              Priority:              Major
Reporter:                 Dominik Gehl                     Assignee:              Dolf Schimmel (Freeaqingme)
Resolution:               Unresolved                       Votes:                 0
Remaining Estimate: Not Specified
Time Spent:               Not Specified
Original Estimate:        Not Specified


Description
The examineOrSelect call in Zend_Mail_Protocol_Imap only returns a fixed subset of attributes of the actual server
response. In particular, the very useful UIDNEXT is not returned




Comments
Comment by Dominik Gehl [ 29/Sep/10 09:48 AM ]
The following patch fixes the problem

@@ -522,6 +522,9 @@
case '[UIDVALIDITY':
$result['uidvalidity'] = (int)$tokens[2];
break;
+ case '[UIDNEXT':
+ $result['uidnext'] = (int)$tokens[2];
+ break;
default:
// ignore
}
Comment by Dominik Gehl [ 29/Sep/10 11:04 AM ]
Here's the patch against a SVN checkout

— library/Zend/Mail/Protocol/Imap.php (revision 23006)
+++ library/Zend/Mail/Protocol/Imap.php (working copy)
@@ -517,6 +517,9 @@
case '[UIDVALIDITY':
$result['uidvalidity'] = (int)$tokens[2];
break;
+ case '[UIDNEXT':
+ $result['uidnext'] = (int)$tokens[2];
+ break;
default:
// ignore
}
[ZF-10503] Zend_Mail::_filterName does not filter ':' Created: 29/Sep/10                                 Updated:
06/Dec/10 Resolved: 06/Dec/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.10.8
Fix Version/s:           Next Major Release

Type:                    Bug                                 Priority:               Major
Reporter:                Richard Vidal                       Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:              Fixed                               Votes:                  0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
Hello,

When an email is sent, ':' character is not allowed in the sender name as it is to represent a group (rfc2822).

this code:

$this->_mail = new Zend_Mail('UTF-8');
$this->_mail->setFrom("john.doe@orange.fr", "John:Doe");

will produce this header:

           From: John:Doe <john.doe@orange.fr>

And it is not correct.

I suggest to disallow ':' in _filterName

Mail.php
--- ZendFramework-1.10.8/library/Zend/Mail.php       2010-01-31
10:06:00.000000000 +0100
+++ ZendFramework-work/library/Zend/Mail.php 2010-09-29 17:31:07.556677100
+0200
@@ -1211,6 +1211,7 @@
         $rule = array("\r" => '',
                       "\n" => '',
                       "\t" => '',
+                                       ':' => '',
                       '"' => "'",
                       '<' => '[',
                       '>' => ']',

I got some really weird results without that patch when an user try to have a sender name with ':'.
That is my first contribution to ZF and I hope it can help.
Comments
Comment by Dolf Schimmel (Freeaqingme) [ 06/Dec/10 03:31 AM ]
This issue has been resolved in ZF2. Thank you for reporting.
[ZF-10501] Zend_Mail_Protocol_Imap : fetch specific parts of message
failed on Dovecot Created: 28/Sep/10 Updated: 28/Sep/10
Status:                   Open
Project:                  Zend Framework
Component/s:              Zend_Mail
Affects Version/s:        1.10.8
Fix Version/s:            None

Type:                     Bug                                    Priority:                  Major
Reporter:                 Vincent Clair                          Assignee:                  Dolf Schimmel (Freeaqingme)
Resolution:               Unresolved                             Votes:                     0
Remaining Estimate: Not Specified
Time Spent:               Not Specified
Original Estimate:        Not Specified


Description
Hello,

I think there is a problem when we request only one specific part. Actually, there is a comparison between id
requested and id answered by imap server. If i fetch for exemple this one on Dovecot:

C: 6 FETCH 19 (BODY.PEEK[1])

I get:
S: * 4827313 FETCH (BODY[1]...
Please notice the lack of ".PEEK".

If I look at RFC 3501 (http://tools.ietf.org/html/rfc3501#section-7.4.2 ), there is no "BODY.PEEK" listed in the
response of a fetch. So, i think Zend_Mail_Protocol_Imap must take this in consideration, if some Imap servers dont
answers full "BODY.PEEK".

Here is a workaround :

if ($tokens[2][0] == $items[0] || $tokens[2][0] == str_replace('BODY.PEEK[',
'BODY[', $items[0])) {
...

I also notice that if we fetch one part in array, the function still answer a string. I think it's not right : if we pass a array
for parameters $from, we are waiting for an array. If we passe a string, so get a string. Maybe it's another bug ?
[ZF-10489] Zend_Mail_Protocol_Imap : problem to get multiline response
Created: 23/Sep/10 Updated: 23/Sep/10
Status:                  Open
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.10.8
Fix Version/s:           None

Type:                    Bug                                   Priority:                Critical
Reporter:                Vincent Clair                         Assignee:                Dolf Schimmel (Freeaqingme)
Resolution:              Unresolved                            Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
Hello,

I have a problem with multiline send by IMAP server. "_nextTaggedLine()" doesn't decode it correctly.

Multiple lines are sent with something similar to that string "{123}\n". So, if a tagged line contains this at the end, get
next lines and add them to current one, while there is a tagged line. Please find here a quick patch :

public function readLine(&$tokens = array(), $wantedTag = '*', $dontParse =
false)
    {
        $line = $this->_nextTaggedLine($tag);

        while (preg_match('/\{\d+\}\s*$/', $line))
        {
          $line = preg_replace('/\{\d+\}\s*$/', '', $line) . $this-
>_nextLine();
        }

             if (!$dontParse) {
                 $tokens = $this->_decodeLine($line);
             } else {
                 $tokens = $line;
             }

             // if tag is wanted tag we might be at the end of a multiline
response
             return $tag == $wantedTag;
         }


Comments
Comment by Vincent Clair [ 23/Sep/10 04:16 AM ]
It seems the problem is more complex. The end "{123}\n" depends of some requests I think.
When i use $imap->fetch('RFC822.HEADERS', 1), the response for the server look like this :

* 42 FETCH (RFC822.HEADER {1606}
Return-Path: <test@test.com>
X-Original-To: test@test.com
Delivered-To: test@test.com
Received: from xxx.ovh.net (localhost.localdomain [127.0.0.1])
[...]

{1606} correspond to the number of bytes to get for the response.

But when i use $imap->requestAndResponse('FETCH', array(1, 'BODYSTRUCTURE'), false), it fails. I expected to
get one line, for all response. Following, as you can see, {9} and others are not the bytes of line length.


* 44 FETCH (FLAGS (\Seen) RFC822.SIZE 486546 UID 99 BODYSTRUCTURE (("application" "pdf" ("name" {9}
16"35.pdf) NIL NIL "base64" 485408 NIL ("inline" ("filename" {9}
16"35.pdf)) NIL NIL) "mixed" ("boundary" "Apple-Mail-1--762503508") NIL NIL NIL) ENVELOPE ("Thu, 16 Sep 2010
13:00:57 +0200" {36}
test piece jointe avec " dans le nom (("Vincent Clair" NIL "test" "test.com")) (("Vincent Clair" NIL "test" "test.com"))
(("Vincent Clair" NIL "test" "test.com")) ((NIL NIL "other" "test.com")) NIL NIL NIL "<F429783B-8CB2-4D83-9EE8-
DFC94DE0DF72@test.com>"))
Maybe the issue http://framework.zend.com/issues/browse/ZF-9714 is linked to
this.
Please take this patch, but i'm not sure that is sufficient :

{code:php}
public function readLine(&$tokens = array(), $wantedTag = '*', $dontParse =
false)
    {
        $line = $this->_nextTaggedLine($tag);

        if (!$dontParse) {
            $tokens = $this->_decodeLine($line);
        } else {
            while (preg_match('/\{\d+\}\s*$/', $line))
            {
              $line = preg_replace('/\{\d+\}\s*$/', '', $line) . $this-
>_nextLine();
            }

                  $tokens = $line;
            }

            // if tag is wanted tag we might be at the end of a multiline
response
            return $tag == $wantedTag;
      }
[ZF-10395] Incorrect validator class used in Zend\Mail\AbstractProtocol
Created: 29/Aug/10 Updated: 06/Nov/10 Resolved: 06/Nov/10
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     Next Major Release
Fix Version/s:         Next Major Release

Type:                  Patch                                Priority:       Blocker
Reporter:              Antoine Hedgecock                    Assignee:       Mickael Perraud
Resolution:            Fixed                                Votes:          0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified


Description
Line 136 in Zend\Mail\AbstractProtocol should be

[code]
$this->_validHost->addValidator(new HostnameValidator(HostnameValidator::ALLOW_ALL));
[/code]




Comments
Comment by Marc Hodgins [ 06/Nov/10 12:24 AM ]
Refers to ZF2. Fixed by Mickael Perraud in github commit a0803a48818cbbcc9dd5
[ZF-10372] Zend_Mail_Transport_Mock Created: 23/Aug/10                                  Updated: 04/Dec/10 Resolved:
04/Dec/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       None
Fix Version/s:           Next Major Release

Type:                    Improvement                           Priority:                 Minor
Reporter:                Till Klampaeckel                      Assignee:                 Dolf Schimmel (Freeaqingme)
Resolution:              Fixed                                 Votes:                    1
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
Found the class in there:
http://framework.zend.com/svn/framework/laboratory/ZFTestManager/Zend/Mail/MailTest.php


I think it would make a great addition.




Comments
Comment by Benoît Durand [ 24/Aug/10 10:11 AM ]
You have a proposal Zend_Mail_Transport_File in the incubator actualy (see
http://framework.zend.com/wiki/pages/viewpage.action?pageId=22642954 ). It is in the same vein, I think. But, I
agree it may be easier to have a class that avoids parse for testing.
Comment by Marc Hodgins [ 06/Nov/10 03:13 AM ]
Not sure I understand the request.

Zend_Mail_Transport_Mock already exists in trunk/tests/Zend/Mail/MailTest.php

What are you proposing?
Comment by Till Klampaeckel [ 06/Nov/10 03:23 AM ]
I'm talking about being able to mock Zend_Mail in my application.


The necessary class to mock Zend_Mail in my app            already exists, but it's hidden inside the tests. It would be nice
if this code is instead put in library where it belongs.
Comment by Dolf Schimmel (Freeaqingme) [ 06/Nov/10 07:34 AM ]
Have you looked at Zend_Transport_Mail?

I'd like to see a usecase why this should be in the library dir. If a good one is provided however, I'll move it to the
library folder in ZF2. Can't do so in 1.11 since it's a BC break / extra functionality and we wont have any other minor
releases after 1.11.
Comment by Till Klampaeckel [ 06/Nov/10 12:01 PM ]
My use case is – bear with me – testing!
We really do TDD and all that. And when I run my unit tests, I don't want to send any emails, yet part of it require a
mail object to be build and used. I want to unit-test though and not involve a mailserver, etc...

Also, this is not a BC break since it doesn't break existing behavior. BC means "backward compatible". This is
preserved by adding an additional driver.
Comment by Dolf Schimmel (Freeaqingme) [ 06/Nov/10 12:09 PM ]
I also mentioned Zend_Mail_Transport_File. Wouldn't that do it for you as well? Also, you can just include file that
currently holds the mockclass.

Though it still has to be considered new functionality, I'll discuss with the release manager if he can make an
exception for this.
Comment by Till Klampaeckel [ 06/Nov/10 12:24 PM ]
Btw, yes I looked into Zend_Mail_Transport_Mail but I don't even want to generate any emails.

It's not the scope of my test. Instead I just want to execute my code and completely mock sending the email. I found
that the class that is hidden in the unit tests for Zend_Mail does this very well.
Comment by Till Klampaeckel [ 06/Nov/10 12:30 PM ]
I saw that you commented also, let me elaborate.

You are of course correct – I can include it already but I usually don't distribute Zend Framework's test suite to
staging and CI.

The problem with using another transport which requires configuration is, that this introduces another potential issues
into my test suite. Probably small, but maybe not. The mock transport does exactly what it should do and it's painless.

With _File, at the bear minimum I need to configure where the files are left, fix it up with permissions and maybe
also clean them up?

Our test suite contains 5000+ tests (and a lot more assertions) and I'm trying to keep test specific configuration at a
bare minimum. Besides, I also enjoy faster tests which need additional disk i/o.
Comment by Wil Moore III (wilmoore) [ 06/Nov/10 12:51 PM ]
As someone who uses the _File transport (I copied the code into my own library and namespaced it), I can
understand the potential cleanup issue. I have not tried this, but I suppose you could direct the files to /dev/null or
something of the sort.

Here is a snippet from my application.ini:

;======================================
; Mail
;======================================
; default mail transport settings
resources.mail.transport.type = "com.example\core\mail\transport\File"
resources.mail.transport.path = BASE_PATH "/tmp/maillog"
resources.mail.transport.register = true

The above block is under the common section. I configure the actual SMTP mailer under the production section. This
way, mail only goes out via production; nothing else.

I personally like the _File transport because it is great for debugging (if necessary; however, I haven't had the need
as of yet).

My unit tests also test that the file was written. I could certainly add a cleanup step (I probably should) but I haven't
done this yet.

Having the _File transport as a part of the actual ZF library would be great as I would not have to maintain my own,
but it works well enough in the interim.

If anyone would like a copy of what I use, just let me know.
Comment by Dolf Schimmel (Freeaqingme) [ 06/Nov/10 12:58 PM ]

         Having the _File transport as a part of the actual ZF library would be great as I would not have to
         maintain my own, but it works well enough in the interim.

It already is. Or do you mean the ZF2 branch/repo? I expect to get to that before the end of this year (probably
earlier).
Comment by Wil Moore III (wilmoore) [ 06/Nov/10 01:02 PM ]

Good point. Yes, I was referring to the 1.x branch. I "borrowed" the code I found from the ZF2 branch
Comment by Dolf Schimmel (Freeaqingme) [ 06/Nov/10 01:39 PM ]
I'm not sure I can follow. You are aware zf1.11 does also have Zend_Mail_Transport_File (though it's only prefixed,
not namespaced)?
Comment by Wil Moore III (wilmoore) [ 06/Nov/10 01:45 PM ]
@Dolf:

Actually, I did not know that. I am still on 1.10.x.
Thanks for the hint.
Comment by Marc Hodgins [ 06/Nov/10 04:00 PM ]
In your own unit tests, if you want a null transport, can't you use a PHPUnit mock for this? Something like

$transport = $this->getMock('Zend_Mail_Transport_Smtp'); // mocks all methods
$mail = new Zend_Mail;
$mail->setBodyText('body')
     ->setFrom('from@domain.com', 'my name')
     ->send($transport);

Or, maybe a class named Zend_Mail_Transport_Null in the library would make more sense than
Zend_Mail_Transport_Mock, if what you're looking to do is have all calls to $mail->send() succeed but not actually
send the mail within a dev environment.
Comment by Dolf Schimmel (Freeaqingme) [ 02/Dec/10 09:23 PM ]
For now I've moved the MockObject to the library dir rather than depending on the test directory.

Marc, your method looks pretty interesting. However, usually you'll want to be testing for the outcome of a method,
rather than its input? Please convince me.
Comment by Marc Hodgins [ 02/Dec/10 10:06 PM ]
Dolf, you're right. My example was limited to needing a null transport when testing other higher level items and not
wanting them to send mail        Wouldn't work for examining the output.
Comment by Dolf Schimmel (Freeaqingme) [ 04/Dec/10 02:18 PM ]
Resolved in ZF2
[ZF-10367] public Zend_Mail::clearHeader() method? Created: 23/Aug/10                                      Updated:
10/Nov/10 Resolved: 26/Oct/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      None
Fix Version/s:          1.11.0

Type:                   New Feature                          Priority:               Minor
Reporter:               Jon Nott                             Assignee:               Marc Hodgins
Resolution:             Fixed                                Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:          ZF-10367.patch

Description
Many of the things you set with public add*() methods on a Zend_Mail object, you can remove again using
corresponding clear*() methods, but this isn't the case with headers.

There is the protected Zend_Mail::_clearHeader() method, but (unless I'm missing something) there isn't a clear
reason why this isn't safe to have a public method for. One shouldn't have to extend Zend_Mail just to clear a header,
when there's already methods like clearRecipients(), clearSubject() etc.

The usage scenario where this would be handy is when you're looping through recipients within the same Zend_Mail
instance, changing some things (e.g. clearRecipients()->addTo('foo@bar.com') ), then calling send() again. You
might've also added some custom header with addHeader() which you then want to remove and add differently for
the next recipient. Presently this is only possible by extending Zend_Mail, or creating a new Zend_Mail instance for
each recipient (which may get problematic if you have things like attachments in the mix).

A public clearHeader() method could be as simple as:

public function clearHeader($headerName)
               {
                       $this->_clearHeader($headerName);

                                    return $this;
                       }


Comments
Comment by Marc Hodgins [ 25/Oct/10 05:52 PM ]
Patch with test attached. Maintains protected _clearHeader() method as a proxy for backwards compatibility for
classes that have extended Zend_Mail.
Comment by Jon Nott [ 26/Oct/10 02:23 AM ]
Would be interesting to know why _clearRecipients() was made a protected method to begin with? Any ideas?
Comment by Dolf Schimmel (Freeaqingme) [ 26/Oct/10 04:56 AM ]
I don't know why the original author, of one of its successors did it like this. I suppose because he doesn't want the
enduser to call it (doh ;D). Zend_Mail suffers from a lot of this kind of decisions and a bad API-design alltogether.
That is why I plan to do a rewrite of its core for ZF2, so we have something that actually works.
Comment by Matthew Weier O'Phinney [ 26/Oct/10 05:51 AM ]
Patch applied to trunk and 1.11 release branch – thanks!
Comment by Jon Nott [ 10/Nov/10 10:04 AM ]
Interestingly, on the subject of backwards-compatibility, this provides an example of how having to work around
weaknesses in the API can actually cause a kind of backwards-incompatibility where framework users have extended
classes to provide those work-arounds.

For example, my work-around for the lack of a public clearHeader() method in Zend_Mail was to create a method in
an extended class which did the reverse of what this patch now does (see my original description above). So if I
upgrade now from ZF 1.10 to 1.11, I actually have to remove my extended public method to avoid an infinite-loop
method calling scenario.

Funny..
[ZF-10328] Zend_Mail : translation of section Additional Headers Created:
17/Aug/10 Updated: 19/Aug/10 Resolved: 19/Aug/10
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     None
Fix Version/s:         1.11.0

Type:                  Docs: Improvement                 Priority:               Minor
Reporter:              Benoît Durand                     Assignee:               Mickael Perraud
Resolution:            Fixed                             Votes:                  0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified

File Attachments:           Zend_Mail-AdditionalHeaders.xml.patch
Language:              French

Description
French translation of this page http://framework.zend.com/manual/en/zend.mail.additional-headers.html




Comments
Comment by Mickael Perraud [ 19/Aug/10 12:08 PM ]
Patch applied with r22854
[ZF-10323] French documentation : refactoring around the word Émail
Created: 16/Aug/10 Updated: 19/Aug/10 Resolved: 19/Aug/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Auth, Zend_Log, Zend_Mail, Zend_Mime, Zend_Service_Flickr, Zend_Session,
                         Zend_Validate
Affects Version/s:       1.10.7
Fix Version/s:           1.11.0

Type:                    Docs: Problem                         Priority:                Minor
Reporter:                Benoît Durand                         Assignee:                Mickael Perraud
Resolution:              Fixed                                 Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

File Attachments:            Archive.zip       ZF-10323.patch
Language:                French

Description
It is disturbing to Frenchify the word "email" by "Émail", and leave invariant in the plural because the plural suffix "ail"
is "aux". I would therefore replace it by "courriel" translation, or "adresse mail".

The specific case of the phrase "email list" by "liste de diffusion".




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 16/Aug/10 11:14 AM ]
your zip file contains much more than documentation. Also, it is preferred that you generate just one patchfile of your
entire changeset.
Comment by Benoît Durand [ 16/Aug/10 11:53 AM ]
Michael told me what he prefers : "regarding the patches, the more little the simpler".
It's easier for me to generate just one patchfile. I add unified patch to leave the choice to the person who will do.
Comment by Mickael Perraud [ 19/Aug/10 12:00 PM ]
Patch applied with r22852
[ZF-10319] "Missing To header" should never been thrown by method
Zend_Mail_Transport_Sendmail::_prepareHeaders() Created: 15/Aug/10 Updated:
25/Oct/10 Resolved: 25/Oct/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.10.7
Fix Version/s:          None

Type:                   Bug                                 Priority:              Major
Reporter:               Carlos Aguado                       Assignee:              Dolf Schimmel (Freeaqingme)
Resolution:             Duplicate                           Votes:                 1
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Duplicate
                        duplicates      ZF-3509    Only adding BCC addresses fails with ...           Resolved

Description
Hi there,

The "Missing To header" exception thrown in line 182 (@version $Id: Sendmail.php 21605 2010-03-22
15:09:03) should never been thrown by method Zend_Mail_Transport_Sendmail::_prepareHeaders().

The reasoning for this is:

1. A "To" header is not required by the underlying PHP's mail() function. See:
http://es2.php.net/manual/en/function.mail.php

2. Using BCC headers with the underlying PHP's mail() function via its $additional_headers optional
parameter is perfectly valid.

3. Throwing this exception here avoids the ability to send anonymous emails via PHP's mail() function
by only using BCC headers injected through the aforementioned $additional_headers optional parameter.

So, throwing this exception should be removed from the method. Please consider and correct.

Thanks a lot, Carlos Aguado.
[ZF-10304] All Bcc's end up in the To line, as well as latter Bcc's get
dumped in the open Created: 12/Aug/10 Updated: 25/Oct/10 Resolved: 25/Oct/10
Status:                 Closed
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.10.7
Fix Version/s:          None

Type:                   Bug                                 Priority:               Major
Reporter:               Scott Connerly                      Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:             Cannot Reproduce                    Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
Similar to

given the following code:

$mail = new Zend_Mail();
$mail->setSubject('my subject');
$mail->setBodyText('my body');
$mail->setFrom('from@myserver.com');
$mail->addTo('to.address@email.com');
$mail->addBcc('first.bcc@email.com');
$mail->addBcc('second.bcc@email.com');
print_r($mail);
$mail->send();

First off, the print_r($mail) output before sending the mail shows the Bcc's as _recipients (which later make their way
onto the To: line

[_headers:protected] => Array
        (
            [Subject] => Array
                (
                    [0] => my subject
                )

                  [From] => Array
                      (
                          [0] => from@myserver.com
                          [append] => 1
                      )

                  [To] => Array
                      (
                          [0] => to.address@email.com
                          [append] => 1
                      )
                  [Bcc] => Array
                      (
                          [0] => first.bcc@email.com
                          [append] => 1
                          [1] => second.bcc@email.com
                      )

            )

      [_from:protected] => from@myserver.com
      [_to:protected] => Array
          (
              [0] => to.address@email.com
          )

      [_recipients:protected] => Array
          (
              [to.address@email.com] => 1
              [first.bcc@email.com] => 1
              [second.bcc@email.com] => 1
          )

The resulting email got the following messed up headers:

To: to.address@email.com,first.bcc@email.com,second.bcc@email.com
From: from@myserver.com
 second.bcc@email.com

When running the test again without the 'From' header, the results are as such:

To: to.address@email.com,first.bcc@email.com,second.bcc@email.com
 second.bcc@email.com

I would mark this higher than Major if at all possible due to the privacy issues involved.

My own alterations to fix this in the short-term include removing the $this->EOL from the implode() inside
_prepareHeaders() and having getRecipients() return $this->_to rather than array_keys($this->_recipients);




Comments
Comment by Marc Hodgins [ 25/Oct/10 04:59 PM ]
Tested against r23236 and cannot reproduce. The unit test for – testZf928ToAndBccHeadersShouldNotMix() located
in tests/Zend/Mail/MailTest.php) – seems to cover this. Please re-open with a working test case if the problem
persists.

What mail transport are you using?
[ZF-10249] Missing inclusion of SMTP status code in
Zend_Mail_Protocol_Exception Created: 30/Jul/10 Updated: 24/Nov/10                           Resolved: 24/Nov/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.10.6
Fix Version/s:           None

Type:                    Bug                                   Priority:                Major
Reporter:                Eutychus                              Assignee:                Marc Hodgins
Resolution:              Duplicate                             Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Issue Links:             Duplicate
                         duplicates      ZF-10741     Zend_Mail_Protocol_Smtp needs unit tests                Resolved

Description
I asked this month before but never received a satisfying answers:

If I Use a Zend_Mail_Transport_Smtp for mail transport. How could I receive the Status code returned by the server
on any errors.

Example: 451 greylisted - try again later

The Zend_Mail_Protocol_Exception only contains the "greylisted - try again later" which may vary between servers.
The getCode() Method only returns 0.

To me this is a bug of the Zend_Mail_Transport_Smtp and I can't believe that noone else had this problem before.




Comments
Comment by Eutychus [ 30/Jul/10 05:43 AM ]
Maybe it could be possible to modify Zend_Mail_Protocol_Abstract::_expect() to submit servers response code via
Exception code (which should solve my problem):

$errCode = 0;
do {
$this->_response[] = $result = $this->_receive($timeout);
list($cmd, $more, $msg) = preg_split('/([\s-]+)/', $result, 2, PREG_SPLIT_DELIM_CAPTURE);

if ($errMsg !== '') { $errMsg .= ' ' . $msg; } elseif ($cmd === null || !in_array($cmd, $code)) {
$errCode = $cmd;
$errMsg = $msg;
}

} while (strpos($more, '-') === 0);

if ($errMsg !== '') {
/**

         @see Zend_Mail_Protocol_Exception
          */
          require_once 'Zend/Mail/Protocol/Exception.php';
          throw new Zend_Mail_Protocol_Exception($errMsg, $errCode);
          }


Comment by Marc Hodgins [ 24/Nov/10 10:09 AM ]
Thanks for the bug report. Addressed this in the patch attached to as it was necessary to have access to the SMTP
status codes for the unit tests on .
Comment by Marc Hodgins [ 24/Nov/10 10:09 AM ]
Closing this ticket as duplicate for now and linking to for resolution.
Evaluate and document ZF overall performance         (ZF-2983)



  [ZF-10208] replace calls of chr([number]) without a variable argument
by a direct string Created: 22/Jul/10 Updated: 22/Jul/10 Resolved: 22/Jul/10
Status:                   Closed
Project:                  Zend Framework
Component/s:              Zend_Crypt, Zend_Json, Zend_Mail, Zend_OpenId, Zend_Pdf, Zend_Translate
Affects Version/s:        1.10.6
Fix Version/s:            1.10.7

Type:                     Sub-task                           Priority:        Trivial
Reporter:                 Marc Bennewitz (private)           Assignee:        Marc Bennewitz (private)
Resolution:               Fixed                              Votes:           0
Remaining Estimate: Not Specified
Time Spent:               Not Specified
Original Estimate:        Not Specified


Description
... like chr(0) -> "\0"

-> search by regexp chr([0-9]*)




Comments
Comment by Marc Bennewitz (private) [ 22/Jul/10 11:48 AM ]
changed in r22653 (trunk) & r22655 (1.10 branch)
[ZF-10200] Zend_Mail Gmail Spam Problem Created: 21/Jul/10                              Updated: 31/Jul/10 Resolved:
31/Jul/10
Status:                        Resolved
Project:                       Zend Framework
Component/s:                   Zend_Mail
Affects Version/s:             None
Fix Version/s:                 None

Type:                          Bug                          Priority:              Major
Reporter:                      Mustafa                      Assignee:              Dolf Schimmel (Freeaqingme)
Resolution:                    Not an Issue                 Votes:                 0
Remaining Estimate: Not Specified
Time Spent:                    Not Specified
Original Estimate:             Not Specified


Description
Hi,

We sent through kayako and zend mail stmp through same mail address but GMAIL recognes zend_mail as spam.
Please see the mail headers below. What is causing this issue?

GMail EMail Headers
-----------------------------------------------
Zend_Mail:

            Delivered-To: XXXX@gmail.com
            Received: by 10.204.67.80 with SMTP id q16cs151167bki;
            Tue, 20 Jul 2010 14:40:22 -0700 (PDT)
            Received: by 10.213.31.208 with SMTP id z16mr7054360ebc.10.1279662022397;
            Tue, 20 Jul 2010 14:40:22 -0700 (PDT)
            Return-Path: <destek@idealxxxx.net.tr>
            Received: from server.idealxxxx.net.tr (server.idealxxxx.net.tr [95.154.241.18])
            by mx.google.com with ESMTP id v8si17781637eeh.52.2010.07.20.14.40.22;
            Tue, 20 Jul 2010 14:40:22 -0700 (PDT)
            Received-SPF: pass (google.com: best guess record for domain of destek@idealxxxx.net.tr
            designates 95.154.241.18 as permitted sender) client-ip=95.154.241.18;
            Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of
            destek@idealxxxx.net.tr designates 95.154.241.18 as permitted sender)
            smtp.mail=destek@idealxxxx.net.tr
            Message-Id: <4c4617c6.887b0e0a.6771.7c26SMTPIN_ADDED@mx.google.com>
            Received: from localhost ([127.0.0.1])
            by server.idealxxxx.net.tr with esmtpa (Exim 4.69)
            (envelope-from <destek@idealxxxx.net.tr>)
            id 1ObKY1-0003Sr-Hn
            for fazo1903@gmail.com; Wed, 21 Jul 2010 00:40:21 +0300
            To: fazo1903@gmail.com
            From: FAZLI - iDealxxxx <destek@idealxxxx.net.tr>
            Subject: [IH-084D-0320] - this is a test mail
            Date: Wed, 21 Jul 2010 00:40:21 +0300
            Content-Type: text/html; charset=UTF-8
            Content-Transfer-Encoding: quoted-printable
            Content-Disposition: inline
            MIME-Version: 1.0
            X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
          X-AntiAbuse: Primary Hostname - server.idealxxxx.net.tr
          X-AntiAbuse: Original Domain - gmail.com
          X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
          X-AntiAbuse: Sender Address Domain - idealxxxx.net.tr

          <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/=
          html4/strict.dtd">=0A<html>=0A<head>=09=0A=09<meta http-equiv=3D"Content=
          -Type" content=3D"text/html; charset=3Dutf-8"/>=0A</head>=0A<body>=0A=0A=
          =09<p>=3D=3D=3D Bu mesaj size iDeal xxxx - Destek Departman=C4=
          =B1ndan gönderilmi=C5=9Ftir. Email'e cevap vermek istiyorsan=C4=B1=
          z konuda herhangi bir de=C4=9Fi=C5=9Fme yapmadan gönderiniz. Bu ti=
          cket'i online olarak görünteleyip, cevap vermek isterseniz;=
          =3D=3D=3D</p>=0A<p>http://panel.idealxxxx.net.tr/support/ticket/view=
          ?id=3D815<br /><br /><br /></p>=0A<p>this is a test mail<br />=0A<br />=
          =0ASayg=C4=B1lar=C4=B1m=C4=B1zla,<br />=0AFAZLI YILMAZ<br />=0AiDeal Hos=
          ting Destek<br /><br /></p>=0A</body>=0A</html>

Kayako:

          Delivered-To: XXXXX@gmail.com
          Received: by 10.204.67.80 with SMTP id q16cs151153bki;
          Tue, 20 Jul 2010 14:39:55 -0700 (PDT)
          Received: by 10.213.34.3 with SMTP id j3mr5291648ebd.64.1279661995228;
          Tue, 20 Jul 2010 14:39:55 -0700 (PDT)
          Return-Path: <destek@idealxxxx.net.tr>
          Received: from server.idealxxxx.net.tr (server.idealxxxx.net.tr [95.154.241.18])
          by mx.google.com with ESMTP id q1si17758591eeh.99.2010.07.20.14.39.55;
          Tue, 20 Jul 2010 14:39:55 -0700 (PDT)
          Received-SPF: pass (google.com: best guess record for domain of destek@idealxxxx.net.tr
          designates 95.154.241.18 as permitted sender) client-ip=95.154.241.18;
          Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of
          destek@idealxxxx.net.tr designates 95.154.241.18 as permitted sender)
          smtp.mail=destek@idealxxxx.net.tr
          Received: from localhost ([127.0.0.1])
          by server.idealxxxx.net.tr with esmtpa (Exim 4.69)
          (envelope-from <destek@idealxxxx.net.tr>)
          id 1ObKXa-0003RC-D5
          for fazo1903@gmail.com; Wed, 21 Jul 2010 00:39:54 +0300
          X-Mailer: Kayako SupportSuite v3.60.04
          X-Priority: 3
          MIME-Version: 1.0
          Date: Wed, 21 Jul 2010 00:39:54 +0300
          Message-ID: <l5vlii.emqpuq@www.idealxxxx.net.tr>
          Subject: CNR-582201: this is a test mail
          Content-Type: multipart/alternative;
          boundary="=_7e8686e6cebe0b87ee7263141037a776"
          From: =?UTF-8?B?RmF6bMSxIFnEsWxtYXogLSBpRGVhbCBI?=
          =?UTF-8?B?b3N0aW5n?= <destek@idealxxxx.net.tr>
          Reply-To: destek@idealxxxx.net.tr
          To: fazo1903@gmail.com
          X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
          X-AntiAbuse: Primary Hostname - server.idealxxxx.net.tr
          X-AntiAbuse: Original Domain - gmail.com
          X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
          X-AntiAbuse: Sender Address Domain - idealxxxx.net.tr

          --=_7e8686e6cebe0b87ee7263141037a776
          Content-Type: text/plain; charset="UTF-8"
          Content-Transfer-Encoding: 8bit
         this is a test mail

         Saygılarımla
         ---------------
         Fazlı Yılmaz

         iDeal xxxx

         2GB Ram - 60 GB HDD - Limitsiz Trafik - Ücretsiz Panel - Linux VPS Aylık 39,99$
         http://www.idealxxxx.net.tr/vps_sunucu.php
         --=_7e8686e6cebe0b87ee7263141037a776
         Content-Type: text/html; charset="UTF-8"
         Content-Transfer-Encoding: 8bit

         <font face="Verdana, Arial, Helvetica" size="2">this is a test mail<br />

         <br />
         Saygılarımla<br />
         ---------------<br />
         Fazlı Yılmaz<br />
         <br />
         iDeal Hosting<br />
         <br />
         2GB Ram - 60 GB HDD - Limitsiz Trafik - Ücretsiz Panel - Linux VPS Aylık 39,99$ <br />
         <a href="http://www.idealxxxx.net.tr/vps_sunucu.php"
         target="_blank">http://www.idealxxxx.net.tr/vps_sunucu.php </a>
         --




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 21/Jul/10 03:40 PM ]
Did you send them from the same host? Same from-address, same to-address?
Comment by Mustafa [ 21/Jul/10 05:32 PM ]
Yes, the same address are sent to same address
Comment by Mustafa [ 25/Jul/10 03:27 PM ]
who can help me yet
Comment by Dolf Schimmel (Freeaqingme) [ 25/Jul/10 03:37 PM ]
What happens if the bodies also are exactly the same? You´ll need to find the one thing that differs on which google
bases its judgement.
Comment by Mustafa [ 30/Jul/10 02:30 PM ]
When we send e-mails via Kayako or Outlock with smtp option, the mail goes to inbox but when we send it with
zend_mail it goes directly to the spam box. Even when we make the mail and subject exactly the same, it goes to the
spam box.
Comment by Dolf Schimmel (Freeaqingme) [ 31/Jul/10 02:03 PM ]
When sending using zend_mail, you are sure you're using an smtp server rather than sendmail?
Comment by Mustafa [ 31/Jul/10 05:32 PM ]
Thankyou for all replies.

I sent once "HELO/EHLO" and my issue solved.
Comment by Dolf Schimmel (Freeaqingme) [ 31/Jul/10 10:23 PM ]

Closing as not an issue. Congratz with your solution
[ZF-10196] Working directory changed in Zend_Mail Created: 21/Jul/10                                        Updated:
24/Sep/10
Status:                  Open
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.10.6
Fix Version/s:           None

Type:                    Bug                                   Priority:                Minor
Reporter:                Freek van Rijt                        Assignee:                Dolf Schimmel (Freeaqingme)
Resolution:              Unresolved                            Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
An error in Zend_Mail is causing the working directory to change, this results in a fatal error when trying to include
Zend\Mail\Protocol\Exception.php, see the following error:

Warning: require_once(Zend/Mail/Protocol/Exception.php) [function.require-once]: failed to open stream: No such file
or directory in D:\www\libraries\Zend\Mail\Protocol\Abstract.php on line 295

Fatal error: require_once() [function.require]: Failed opening required 'Zend/Mail/Protocol/Exception.php'
(include_path='../libraries;../application/controllers;../application/models;../application/models/system;../application/for
ms;../../libraries') in D:\www\libraries\Zend\Mail\Protocol\Abstract.php on line 295

This error has also been reported by other users, see here: http://www.mail-archive.com/fw-
general@lists.zend.com/msg13596.html and here: http://stackoverflow.com/questions/1605918/problem-with-
sending-emails-using-zend-mail




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 21/Jul/10 05:43 AM ]
What code do you execute, what is the expected outcome?

Please also attach a stack trace, and please note that it is encouraged to use absolute paths in your include path.
Comment by Freek van Rijt [ 21/Jul/10 06:05 AM ]
Its happening when simply trying to send a mail. What would be the easiest way for me to get the stack trace for the
issue?
Comment by Freek van Rijt [ 21/Jul/10 06:59 AM ]
Would this be of any help. I ran a backtrace just above the line where the error was triggered:

#0 Zend_Mail_Protocol_Abstract->_send(QUIT) called at [D:\www\libraries\Zend\Mail\Protocol\Smtp.php:385]
#1 Zend_Mail_Protocol_Smtp->quit() called at [D:\www\libraries\Zend\Mail\Transport\Smtp.php:144]
#2 Zend_Mail_Transport_Smtp->__destruct()
Comment by Dolf Schimmel (Freeaqingme) [ 21/Jul/10 07:58 AM ]
Thanks, all that method basically does is call fclose(). Can you please check if this error also happens on linux?

And as mentioned; it is suggested you use absolute paths in your include path rather than relative paths.
Comment by Freek van Rijt [ 21/Jul/10 08:14 AM ]
Yes, I ran the same script on our test server (which runs linux) and got the same result. It does send the email out
though, it looks like where it goes wrong is when it tries to close the connection to the server?
Comment by Dolf Schimmel (Freeaqingme) [ 21/Jul/10 08:19 AM ]
Out of curiosity, why dont you use absolute paths?
Comment by Freek van Rijt [ 21/Jul/10 08:26 AM ]
We have three seperate environments here - dev: which is basically the local PC, test: which is a closed off test-
environment on our server, and production, which is the live environment. Because of this, the path is basically
variable, defining it absolute would mean people having to edit it seperately for their own local environment (dev) and
also changing it whenever the site goes on test or production environments. We use SVN to exchance it and sync it
with our server, so conflicts would be lurking as well. Defining it relative saves all this hassle, and it doesnt matter
where on the local filesystem we put the site.

Also it means we dont have to edit the paths for each individual site we produce.
Comment by Dolf Schimmel (Freeaqingme) [ 21/Jul/10 08:26 AM ]
I traced down the problem to the php manual:

          Note: Destructors called during the script shutdown have HTTP headers already sent. The working
          directory in the script shutdown phase can be different with some SAPIs (e.g. Apache).

(http://php.net/manual/en/language.oop5.decon.php )

I will have to discuss this but I think it will be closed as wont-fix with the note to simply use absolute paths.
Comment by Dolf Schimmel (Freeaqingme) [ 21/Jul/10 08:29 AM ]
Frankly, that reason is bogus. You can dynamically determine the absolute path. As is shown in basically any ZF
tutorial:

// Define path to application directory
defined('APPLICATION_PATH')
    || define('APPLICATION_PATH', realpath(dirname(__FILE__) .
'/../application'));

// Define application environment
defined('APPLICATION_ENV')
    || define('APPLICATION_ENV', (getenv('APPLICATION_ENV') ?
getenv('APPLICATION_ENV') : 'production'));

// Ensure library/ is on include_path
set_include_path(implode(PATH_SEPARATOR, array(
     realpath(APPLICATION_PATH . '/../library'),
     get_include_path(),
)));

That will dynamically set an absolute include path.
Comment by Freek van Rijt [ 21/Jul/10 08:40 AM ]
So silly I didn't think of that, changing it to

$sLibraryPath = realpath(dirname(_FILE_)."../../../libraries");{/noformat}
Solved the issue.

Guess the issue is more related to the PHP core rather then Zend itself anyway. Thanks for the help!
Comment by jsnod [ 22/Sep/10 06:41 PM ]
I am having a similar issue, with a slight difference: PHP complains about an open_basedir restriction. Here is my
error:

Warning: require_once() [<a href='function.require-once'>function.require-
once</a>]: open_basedir restriction in effect.
File(Zend/Mail/Protocol/Exception.php) is not within the allowed path(s):
(/home/username/:/tmp/:/usr/share/pear/:/dev/) in
/usr/share/pear/ZendFramework-1.10.8-
minimal/library/Zend/Mail/Protocol/Abstract.php on line 295
Fatal error: Can't load Zend/Mail/Protocol/Exception.php, open_basedir
restriction. in /usr/share/pear/ZendFramework-1.10.8-
minimal/library/Zend/Mail/Protocol/Abstract.php on line 295

This is odd because my open_basedir value is set to:

php_admin_value open_basedir "/home/username/:/tmp/:/usr/share/pear/:/dev/"

My include paths are already absolute, and look like so:

/home/username/library:/home/username/application/models:/home/username/appli
cation/models/notifications:/usr/share/pear

ZF resides in /usr/share/pear/, so by all indications the file should be able to be found and require'd because it exists
in the include_path and my include_path is allowed in open_basedir. If I remove the open_basedir restriction it works
as expected, however, I'd rather not do that for security reasons.
Comment by jsnod [ 24/Sep/10 12:40 PM ]
After doing additional tests/research, you are right, this is an issue with PHP. The current working directory changes
to '/' before object-destructors are called, which is why my open_basedir or throwing an error.

http://bugs.php.net/bug.php?id=31570


Not sure if this is classified as a "feature" or a "bug" though.
[ZF-10157] The body of an email when sent from a controller action
includes extraneous  Created: 14/Jul/10 Updated: 16/Jul/10 Resolved: 16/Jul/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Db, Zend_Mail
Affects Version/s:      None
Fix Version/s:          None

Type:                   Bug                                Priority:               Trivial
Reporter:               John Worthington                   Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:             Fixed                              Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
I have tried using both Zend_Mail and PHPMailer to send email from a controller action.
The Htmlbody is - 'This is a test message '

The received message is - 'Â This is a test message '

In checking the body via dump, its content does not include the Â.

With a larger body, the A circ appears on paragraph breaks, copyrights.
e.g.
This email confirms that you have requested to be added to the Healthy Aging® Newsletter mailing list. Every
month,you will receive an email newsletter containing news, ideas, and tips for positive aging from Healthy
Aging®.Â

Without using the framework, both mailers work properly. I have used different smtp servers identical results

My platform is XP sp3 and xampp.

Can you guide me to a solution?

Thanks




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 14/Jul/10 04:59 PM ]
Can you please provide some code with which the issue can be reproduced?
Comment by John Worthington [ 15/Jul/10 10:24 AM ]
In creating a subset of my application, I was able to successfully send emails from module controllers with both
Zend_Mail and PHPMailer.

This allowed me to focus on the source of my problem. The email body is created under dijit editor and saved in a
MySql table. When the content is passed from the table row to the BodyHtml, it gets corrupted. The corruption is not
obvious. I can copy the html source from the editor, place it in a var and pass this to Body. This works fine.
The question becomes - How do I insure that the editor output is not corrupted?

The code for sending is: Echoing the column matches what is in the $msg. $values['htmltext'] is the column values.

$values['htmltext'] email has the body sample 'The Body with comments'.

CODE
public function sendAction() {
$msg = '<div><span style="font-size: medium;"><h3><b><span style="FONT-SIZE: x-large">This is a test
message</span></b></h3><h3><div><span style="FONT-SIZE: 12px; FONT-STYLE: italic; FONT-FAMILY:
Arial">You
don\'t grow old... ';
$msg .= 'you become old by not growing! Say NO to retirement with
the <a href="http://www.cardpartner.com/app/healthy-aging">Healthy
Aging</a>card</span></div></h3></span></div>'; echo $msg;
$msg = '<span style="font-size: x-large">The Body</span> with comments';
$recid = $this->_getParam('recid', 0); echo $recid;
$_clientModel = new Hdb_Model_Project();;
$row = $_clientModel->getAutoresprow($recid);
foreach($row as $rowd) { break; }
$values = $rowd->toArray();
$msg = $values['htmltext'];
echo $values['htmltext'];

$mail = new Zend_Mail();

try { $mail->setBodyHtml($msg) ->setFrom('jhwrthngtn@snet.net', 'Some Sender') ->addTo('jhwrthngtn@snet.net',
'Some Recipient') ->setSubject('TestSubject') // ->addAttachment($at) ->send(); var_dump($mail); }
catch (Exception $e) { echo 'Error: ' . $e->getMessage(); //Boring error messages from anything else! }
}
Comment by John Worthington [ 15/Jul/10 04:06 PM ]
The problem is the dijit editor adds '/Â/' in the post params from the form editor.

My approach is to filter the '/Â/' before saving in the DB.

I wonder why I need to do this filtering.

Are there parameters that I should set in the form to get clean output?

The form code is below.
<?php
class Hdb_Form_AutorespEdit extends Zend_Dojo_Form
{
public $_codeOptions;

public function __construct( $options=null)

{ Zend_Dojo::enableForm($this); $recid = new Zend_Form_Element_Hidden('recid'); $this-
>setDisableLoadDefaultDecorators(true); $this->setDecorators(array( array('ViewScript',
array('viewScript'=>'/autoresp/_autorespedit.phtml') ),'Form' )); $created = new Zend_Form_Element_Text ('created',
array('decorators'=> array('ViewHelper'), 'readonly' => true, )); $updated = new Zend_Form_Element_Text ('updated',
array('decorators'=> array('ViewHelper'), 'readonly' => true, )); $recid = new Zend_Form_Element_Text('recid',
array('decorators'=> array('ViewHelper'), 'readonly' => true, )); $parent = new Zend_Form_Element_Text('parent',
array('decorators'=> array('ViewHelper'), 'size' => '60px', 'maxlength' => '63', )); $imgurl = new
Zend_Form_Element_Text('imgurl', array('decorators'=> array('ViewHelper'), 'size' => '60px', 'maxlength' => '63', ));
$subject = new Zend_Form_Element_Text('subject', array('decorators'=> array('ViewHelper'), 'size' => '80px',
'maxlength' => '255', )); // $htmltext = new Zend_Form_Element_Editor('htmltext', // array('decorators'=>
array('ViewHelper'),)); $this->addElement( 'editor', 'htmltext', array( 'label' => 'Editor', 'inheritWidth' => 'true', //
'extraplugins' => array('viewsource','foreColor','hiliteColor') ) ); $ed = $this->getElement('htmltext'); $fmt
=array('viewsource',
'bold','italic','underline','strikethrough','insertOrderedList','insertUnorderedList','blockquote','link','unlink','image');
array_push(
$fmt,'foreColor','hiliteColor','cut','copy','paste','|','bold','italic','underline','strikethrough','subscript','superscript','|');
array_push($fmt, 'indent', 'outdent', 'justifyLeft', 'justifyCenter', 'justifyRight','fontName','fontSize','formatBlock'); $ed-
>addPlugins($fmt); $update = new Zend_Form_Element_Submit('update'); $update->setAttrib('id', 'submitbutton') -
>setLabel('Update'); $insert = new Zend_Form_Element_Submit('insert'); $insert->setAttrib('id', 'submitbutton') -
>setLabel('Send'); $this->addElements(array($recid, $parent,$imgurl, $subject, $insert, $update,$created,$updated));
}

}
?>
Comment by John Worthington [ 16/Jul/10 01:46 PM ]
On further investigation, I find that my problem is in reading the DB_Table_Row.

A value such as 'Aging®' will store in the row properly.


When the row is read the value is 'Aging� '.

I do not see in the documentation how to retrieve rows containing special characters.

The escaping of '®' does not work.

Guidance would be appreciated.
Comment by Dolf Schimmel (Freeaqingme) [ 16/Jul/10 01:50 PM ]
You probably forgot to set a charset somewhere correctly. Please seek help through the proper support channels
(mailinglists, irc, forums, etc).

Good luck!
[ZF-10130] Zend_Mail sets wrong Content-Transfer-Encoding in mail-
header in MULTIPART Mime mails (INCLUDES BUGFIX) Created: 10/Jul/10 Updated:
06/Dec/10 Resolved: 06/Dec/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.10.6
Fix Version/s:          Next Major Release

Type:                   Bug                               Priority:               Major
Reporter:               Andreas F.                        Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:             Fixed                             Votes:                  2
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Related
                        is related to    ZF-9262   Multipart mail Content-Transfer-Encod...             Resolved

Description
When sending Multipart Mime-Email Zend_Mail sets the value of the field "Content-Transfer-Encoding" in mail-
header to the value of BodyText (which is wrong!)

This results in a violation of RFC when BodyText is (as example) encoded as "quoted-printable" and can result in
refusal of the mail from the mail-receivers MUA or MTA.

Best Practice is: DO NOT SET "Content-Transfer-Encoding" in mailheader, when sending Multipart Mime-Emails.

Example code to reproduce the error:

$mail = new Zend_Mail();
  $mail->setBodyText('some text','ISO-8859-
1',Zend_Mime::ENCODING_QUOTEDPRINTABLE);
  $mail->setFrom('xx@xxx.de');
  $mail->addTo('xx@xxx.de');
  $mail->setSubject('Test');
  $at = new Zend_Mime_Part('some unimportant content');
  $at->type        = 'application/pdf';
  $at->disposition = Zend_Mime::DISPOSITION_ATTACHMENT;
  $at->encoding    = Zend_Mime::ENCODING_BASE64;
  $at->filename    = 'blafasel.pdf';
  $mail->addAttachment($at);
  $mail->send();

The created email looks like this in source:

Subject: Test
To: xx@xxx.de
From: xx@xxx.de
Date: Sat, 10 Jul 2010 07:16:15 -0200
Content-Type: multipart/mixed;
 boundary="=_03fcaaf5c6e236d86e4353bccf196a7d"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
MIME-Version: 1.0
Message-Id: <20100710091618.B221A124@xxxx.xxxx.de>

This is a message in Mime Format.                         If you see this, your mail reader does not
support this format.

--=_03fcaaf5c6e236d86e4353bccf196a7d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

some text
--=_03fcaaf5c6e236d86e4353bccf196a7d
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="blafasel.pdf"

c29tZSB1bmltcG9ydGFudCBjb250ZW50
--=_03fcaaf5c6e236d86e4353bccf196a7d--

The line "Content-Transfer-Encoding: quoted-printable" direct below "Content-Type: multipart/mixed;
boundary="=_03fcaaf5c6e236d86e4353bccf196a7d" is a violation of RFC.

The error could be corrected in File Zend/Mail/Transport/Abstract.php in function

public function send(Zend_Mail $mail)

by adding at line 334 the following two lines of code:

if (isset($boundary))
    unset($this->_headers['Content-Transfer-Encoding']);

So the function will look like this from the beginning (just for clarifiation):

public function send(Zend_Mail $mail)
    {
        $this->_isMultipart = false;
        $this->_mail        = $mail;
        $this->_parts       = $mail->getParts();
        $mime               = $mail->getMime();

             // Build body content
             $this->_buildBody();

             // Determine number of parts and boundary
             $count    = count($this->_parts);
             $boundary = null;
             if ($count < 1) {
                 /**
                  * @see Zend_Mail_Transport_Exception
                  */
                 require_once 'Zend/Mail/Transport/Exception.php';
                  throw new Zend_Mail_Transport_Exception('Empty mail cannot be
sent');
            }

            if ($count > 1) {
                // Multipart message; create new MIME object and boundary
                $mime     = new Zend_Mime($this->_mail->getMimeBoundary());
                $boundary = $mime->boundary();
            } elseif ($this->_isMultipart) {
                // multipart/alternative -- grab boundary
                $boundary = $this->_parts[0]->boundary;
            }

            if (isset($boundary))
                unset($this->_headers['Content-Transfer-Encoding']);

           ... the rest of the function follows here ...

It would be nice if someone could apply this fix to the next version of Zend_Framework.

Thanks
Andreas




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 06/Dec/10 03:14 AM ]
I'd like to know where and in which rfc I can find this. In any ways, it did get resolved in ZF2
[ZF-10092] POP3 in Exchange Server 2003 - wrong multiline response
Created: 01/Jul/10 Updated: 01/Jul/10
Status:                    Open
Project:                   Zend Framework
Component/s:               Zend_Mail
Affects Version/s:         1.10.6
Fix Version/s:             None

Type:                      Bug                                     Priority:        Major
Reporter:                  Michal Tulá?ek                          Assignee:        Dolf Schimmel (Freeaqingme)
Resolution:                Unresolved                              Votes:           0
Remaining Estimate: Not Specified
Time Spent:                Not Specified
Original Estimate:         Not Specified


Description
Hi,

I found that in the Exchange Server 2003 the response of message sometimes contains faultly a single dot on line
while it is not end of the message. But Zend_Mail_Protocol_Pop3 identifies that dot as an end of the message and
therefore it cannot read the whole message and also leave the rest of message on the socket (which effectively
disables the whole rest of the communication with the server).

I looked in the POP3 RFC and it is definitely the ES2003 fault. However, the server is still used and we need to live
with that. Therefore i suggest to change part of the readResponse method to something similar to this:

if ($multiline) {
$message = '';
$line = fgets($this->_socket);
$stat = socket_get_status($this->_socket);
$queue = $stat['unread_bytes']; // How many bytes to read from socket?

while (($line && rtrim($line, "\r\n") != '.') || ($queue > 0)) {
if ($line[0] == '.') { $line = substr($line, 1); }
$message .= $line;
$line = fgets($this->_socket);

$stat = socket_get_status($this->_socket);
$queue = $stat['unread_bytes']; // How many bytes to read from socket?
};
}

It works fine with the ES2003, however I havent try it on another POP3 server. It could also be affected by the fact,
that the connection is estabilished with ES2003, and so on...
[ZF-9992] Allow Zend_Log_Writer_Mail to specify a transport Created: 15/Jun/10
Updated: 15/Jun/10
Status:                 Open
Project:                Zend Framework
Component/s:            Zend_Log, Zend_Mail
Affects Version/s:      1.10.2
Fix Version/s:          None

Type:                   Patch                               Priority:                Major
Reporter:               Juan Pablo Civile                   Assignee:                Eddo Rotman
Resolution:             Unresolved                          Votes:                   1
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:          patch-writer-mail

Description
Added a 3rd param to the Zend_Log_Writer_Mail constructor to optionally accept a Zend_Mail_Transport_Abstract
instance to use as transport when sending the mail.




Comments
Comment by Juan Pablo Civile [ 15/Jun/10 02:13 PM ]
Propossed patch.
Comment by Juan Pablo Civile [ 15/Jun/10 03:02 PM ]
This patch was born out of the necessity of having more than one mail log writer with different mailing criteria. Without
setting different transport for each of them, an error would occur when PHP closed some of the resources after
sending the mails from the first writer, throwing an exception when the second writer attempted to send an email.
[ZF-9959] Zend_Mail fails with postfix mailserver Created: 08/Jun/10                                Updated: 08/Jun/10
Status:                   Open
Project:                  Zend Framework
Component/s:              Zend_Mail
Affects Version/s:        1.10.5
Fix Version/s:            None

Type:                     Bug                                Priority:              Major
Reporter:                 Stephan Hochdörfer                 Assignee:              Nico Edtinger
Resolution:               Unresolved                         Votes:                 0
Remaining Estimate: Not Specified
Time Spent:               Not Specified
Original Estimate:        Not Specified


Description
When using Zend_Mail with the SMTP transport talking to a postfix mail server that is configured with
strict_mime_encoding_domain = true sending multipart messages will fail. The posfix configration option seems to
block mails from "from poorly written software" as the postfix manual states. It seems that the postfix mailserver has a
problem when the content-transfer encoding and the content-disposistion fields where set in the mail header. If I
removed them the mail transmission did work.

My current work-a-round is to extend Zend_Mail_Transport_Smtp and overwrite the _getHeaders method with:

protected function _getHeaders($boundary)
{
parent::_getHeaders($boundary);

if (null !== $boundary) { unset($this->_headers['Content-Transfer-Encoding']); unset($this->_headers['Content-
Disposition']); }

return $this->_headers;
}

Please have a look at that issue and provide a better fix.
[ZF-9921] Zend_Mail: Allow multiple ReplyTo addresses Created: 31/May/10                                         Updated:
06/Dec/10 Resolved: 06/Dec/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.10.2
Fix Version/s:          Next Major Release

Type:                   Improvement                          Priority:                Minor
Reporter:               Jonas Völcker                        Assignee:                Dolf Schimmel (Freeaqingme)
Resolution:             Fixed                                Votes:                   0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:           Mail.php
Issue Links:             Related
                         is related to      ZF-2219      addBcc() lacks 'name' parameter                   Resolved

Description
Multiple setReplyTo()-calls are currently prohibited and throw an Exception. This is unneeded, as the RFC822 (and
the superceeding RFC2821) allow more than one reply-to header.

I added the capability to add multiple reply-to headers to the Mail.php code, as this was a feature I needed. I tried to
stay in your coding-style, please consider this as an addition to your framework.

I propose the renaming to addReplyTo(), this would also be in style with addTo() etc.

Please find attached the modified Mail.php

Best regards,

Jonas Völcker

PS: I also fixed while I was at it (addBcc() lacks 'name' parameter).




Comments
Comment by Jonas Völcker [ 31/May/10 11:14 AM ]
Attached modified Mail.php with addReplyTo instead of setReplyTo, allowing multiple reply-to headers.
Comment by Satoru Yoshida [ 12/Jun/10 06:52 AM ]
Sorry, I have been inactive since last April.
Comment by Dolf Schimmel (Freeaqingme) [ 06/Dec/10 03:35 AM ]
Resolved in ZF2. Thank you for reporting this issue.
[ZF-9876] Override maximum_log in Zend_Mail_Protocol_Abstract Created:
22/May/10 Updated: 20/Jul/10 Resolved: 16/Jul/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.10.4
Fix Version/s:          1.11.0

Type:                   Improvement                           Priority:                Major
Reporter:               Frank                                 Assignee:                Dolf Schimmel (Freeaqingme)
Resolution:             Fixed                                 Votes:                   3
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:           ZF-9876.patch

Description
In my app, I want to log the whole SMTP transaction. To do so, I'm using:

$tr->getConnection()->getLog()

{/quote}

This works and provides me with the SMTP transaction, however.. its length is limited.
Upon further investigation there is an hard coded value MAXIMUM_LOG in Zend_Mail_Protocol_Abstract.

I've (temporarily) modified this from 64 to 4096 so it covers the whole transaction.In my app I remove everything
between DATA and the
trailing .

Can there be a setter (and getter) to modify this limit?




Comments
Comment by Frank [ 27/May/10 09:43 AM ]
Maybe its also possible to add an option to disable the limit/checking of the limit.
Setting it to 999999 isn't very pretty.
Comment by Josh Boyd [ 09/Jun/10 02:14 PM ]
Patch attached.
Comment by Satoru Yoshida [ 12/Jun/10 06:28 AM ]
Sorry, I have been inactive since last April.
Comment by Dolf Schimmel (Freeaqingme) [ 12/Jun/10 10:00 AM ]
I will review the patch this week and commit it if okay.
Comment by Frank [ 23/Jun/10 01:10 PM ]

Dolf, I hope you haven't forgot about this?
Comment by Michael Kliewe [ 15/Jul/10 11:35 AM ]
I would also love to see a change here because I have the problem that I want to send a mail with attachments
>100MB, and my php memory limit of 512 MB is exhausted, I think this log is one of the problems.
I would like to disable logging completly, setting MAXIMUM_LOG to 0 is not enough because the big DATA request
would be logged anyway into $this->_log and fill up my memory.
Comment by Michael Kliewe [ 15/Jul/10 11:55 AM ]
Forget the sentence with the big DATA request, I have seen that there are thousands of little log entries instead of
one big log entry when sending a big mail.

But I would like to disable this log per default because 99% of the users don't need it, it only wastes CPU. If a
developer needs the log he can enable it then, but default should be off. Or default of $_maximumLog should be -1
which disable the log. In _addLog there has to be one line

if ($this->_maximumLog < 0) return;
Comment by Dolf Schimmel (Freeaqingme) [ 16/Jul/10 03:05 PM ]
Resolved on trunk and will be released in the next major release.

Please beware that I'm unsure why originally it was chosen to use a constant for this. If it turns out there was a proper
reason for that that's still legit this patch will be reverted.

In any case; thank you for reporting this issues and my apologies for the delays in fixing it.
Comment by Josh Boyd [ 16/Jul/10 03:34 PM ]
Your commit is wrong, getMaximumLog is incorrectly named setMaximumLog.
Comment by Dolf Schimmel (Freeaqingme) [ 16/Jul/10 03:38 PM ]
Should be fixed once again. Thanks.
Comment by Michael Kliewe [ 20/Jul/10 08:13 AM ]
I checked your commit, Dolf, and I cannot see a possibility to disable the log. Should I create a new issue for that?

Because I don't want to log the transaction in production environment, and logging every line is a performance
problem, because in my tests when sending a 60MB mail I have 300.000 calls of _addLog and also 300.000 calls of

$this->_log[] = $value;

Best solution would be to have something like

// Save request to internal log
if (true == $this->_loggingEnabled) {
    $this->_addLog($request . self::EOL);
}

in both _send() and _receive() so we don't have thousands of function calls.

Perhaps in ZF 2.0 we could even disable this logging feature by default because only developers need it for
debugging, 99% of the users don't need that logging feature in a default installation. This would increase the
performance of the component. But this would be a BC.
Comment by Josh Boyd [ 20/Jul/10 08:40 AM ]
Just call setMaximumLog(0) and logging is disabled.
Comment by Michael Kliewe [ 20/Jul/10 10:16 AM ]
@Josh: I don't see it, could you please tell me the line? There is no "return" or something in _addLog(), so the
function _addLog() is called every time and an entry is filled into the array $this->_log . You are right that this entry is
shifted out on the next call of _addLog(), but it keeps filling the array 300.000 times.
[ZF-9841] Provide a public method to remove a previously added custom
header Created: 15/May/10 Updated: 02/Dec/10 Resolved: 02/Dec/10
Status:                   Closed
Project:                  Zend Framework
Component/s:              Zend_Mail
Affects Version/s:        1.10.0, 1.10.1, 1.10.2, 1.10.3, 1.10.4
Fix Version/s:            1.11.0

Type:                     Improvement                          Priority:             Major
Reporter:                 Sudheer Satyanarayana                Assignee:             Unassigned
Resolution:               Duplicate                            Votes:                0
Remaining Estimate: Not Specified
Time Spent:               Not Specified
Original Estimate:        Not Specified


Description
Once you add a custom header on the Zend_Mail object, there's no way to remove it.

For example:

$mail = new Zend_Mail();
$mail->addHeader('List-Unsubscribe', 'somevalue');

There's no way to remove the List-Unsubscribe header.

You could provide public clearHeader($headerName) and proxy it to protected _clearHeader($headerName) method.

Then you could remove the List-Unsubscribe header already set usig
$mail->clearHeader('List-Unsubscribe');

I'm willing to provide a patch with unit test, if the suggestion is accepted.




Comments
Comment by Artem Stepin [ 27/May/10 11:26 PM ]
It is a good idea. You would have to pay attention to the fact that you don't allow to delete standart headers defined in
addHeader. The headers are stored in an array with the header name as key. Maybe you could provide an additional
offset parameter in clearHeader($name,$offset = null) to allow delete only one header from the list or all headers with
the given name.

Regards,
Artem Stepin
Comment by Satoru Yoshida [ 12/Jun/10 06:34 AM ]
Sorry, I have been inactive since last April.
Comment by Marc Binder [ 19/Oct/10 12:13 AM ]
Nice idea. If the team is confirm my contribution i implement this net method.
Comment by John Kelly [ 02/Dec/10 02:23 PM ]
Duplicate of and fixed.
[ZF-9821] _formatAddress only quotes names containing '@' or ',' Created:
10/May/10 Updated: 17/Feb/11 Resolved: 17/Feb/11
Status:                        Resolved
Project:                       Zend Framework
Component/s:                   Zend_Mail
Affects Version/s:             1.10.4
Fix Version/s:                 1.11.4

Type:                          Bug                           Priority:            Trivial
Reporter:                      Dave Marshall                 Assignee:            Alexander Veremyev
Resolution:                    Fixed                         Votes:               1
Remaining Estimate: Not Specified
Time Spent:                    Not Specified
Original Estimate:             Not Specified

File Attachments:                  patch.txt

Description
I receive the following error when sending to a particular mail exchange

           5.1.0 - Unknown address error 550-'Rejected after DATA: missing or malformed local part
           (expected word or\n"<"): failing address in "To" header is:\nDave Marshall [Director]
           <email@example.com>

From what I can see here http://tools.ietf.org/html/rfc5322#page-13 , the following characters should force the name
part to be quoted:

"(", ")", "<", ">", "[", "]", ":", ";", "@", "\", ",", "."

Feel free to reject this if I've misinterpreted the RFC!




Comments
Comment by Dave Marshall [ 10/May/10 01:37 AM ]
Patch and simple test
Comment by Satoru Yoshida [ 12/Jun/10 06:14 AM ]
Sorry, I have been inactive since last April.
Comment by John Kelly [ 02/Dec/10 02:50 PM ]
This patch seems to work well. Does someone want to commit this?
Comment by Alexander Veremyev [ 17/Feb/11 05:29 AM ]
Fixed.
[ZF-9802] Unable to use shorthand names for Zend_Mail_Transport type
in Zend_Application configs Created: 04/May/10 Updated: 07/Jan/11 Resolved: 05/May/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Application_Resource, Zend_Config, Zend_Mail
Affects Version/s:       1.10.4
Fix Version/s:           None

Type:                    Bug                                  Priority:                Minor
Reporter:                jsnod                                Assignee:                Dolf Schimmel (Freeaqingme)
Resolution:              Cannot Reproduce                     Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

File Attachments:           Zend_Application_Resource_Mail.diff

Description
When implementing the Zend_Application_Resouce_Mail for use of sendmail via configs as outlined at
http://framework.zend.com/manual/en/zend.application.available-resources.html#zend.application.available-
resources.mail , using shorthand in resources.mail.transport.type (eg: 'smtp') does not work, giving the following
error:

Warning: include(smtp.php) [function.include]: failed to open stream: No such
file or directory in /path/to/app/public/index.php(38) : runtime-created
function on line 1

Warning: include() [function.include]: Failed opening 'smtp.php' for
inclusion (include_path='/path/to/ZendFramework') in
/path/to/app/public/index.php(38) : runtime-created function on line 1

Warning: include(smtp.php) [function.include]: failed to open stream: No such
file or directory in /path/to/app/public/index.php(38) : runtime-created
function on line 1

Warning: include() [function.include]: Failed opening 'smtp.php' for
inclusion (include_path='/path/to/ZendFramework') in
/path/to/app/public/index.php(38) : runtime-created function on line 1

Fatal error: Class 'smtp' not found in
/path/to/ZendFramework/library/Zend/Application/Resource/Mail.php on line 140

Using the longhand like so works:

resources.mail.transport.type = Zend_Mail_Transport_Smtp

But this differs from the docs, so either the docs need to be updated to reflect the need to use the full name for
transport type, or the _setupTransport() method needs to be updated in Zend_Application_Resource_Mail to allow
shorthanded transport types. I personally think it's cleaner to allow shorthanded transport names, and based on a
quick look at the _setupTransport() method, it looks like that is the intent. I'm going to give a shot at a patch and will
post here if I am successful.
Comments
Comment by Dolf Schimmel (Freeaqingme) [ 04/May/10 08:18 PM ]
Could it be there is a file called smtp.php or Smtp.php in your include path? The unittests thoroughly test the behavior
you describe and as such I'm not able to reproduce this issue.

Awaiting more info on how to reproduce this issue.
Comment by jsnod [ 04/May/10 08:42 PM ]
Nope, the only smtp.php in my include path is the one in Zend/Mail/Transport.

To reproduce, put the following in your application.ini:

resources.mail.transport.type                              =   smtp
resources.mail.transport.host                              =   "smtp.server.com"
resources.mail.transport.auth                              =   login
resources.mail.transport.username                          =   "myLogin"
resources.mail.transport.password                          =   "myPasswd"

The above does not work. The config below works fine:

resources.mail.transport.type                              =   Zend_Mail_Transport_Smtp
resources.mail.transport.host                              =   "smtp.server.com"
resources.mail.transport.auth                              =   login
resources.mail.transport.username                          =   "myLogin"
resources.mail.transport.password                          =   "myPasswd"

I've whipped up a quick patch that works for both cases, will attach. It's my first time submitting a patch, so please
forgive me if I've done it wrong.
Comment by Dolf Schimmel (Freeaqingme) [ 05/May/10 06:54 AM ]
The problem with your patch is that it doesn't allow for transport names like
someOtherLib_Mail_Transport_SmtpFoobar. I'm closing this issue as cannot reproduce until you're able to provide a
unittest, or more information on how to reproduce.
[ZF-9789] Zend/Mail/Part getHeader doesn't allow for nested arrays Created:
02/May/10 Updated: 04/Dec/10
Status:                  Open
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       None
Fix Version/s:           None

Type:                    Bug                                   Priority:                  Minor
Reporter:                Dave Edelhart                         Assignee:                  Dolf Schimmel (Freeaqingme)
Resolution:              Unresolved                            Votes:                     0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
works fine for flat arrays but for nested arrays (nested multipart bodys specifially) requries iterative reduction.

Recommendation:
class Zend_Mail_Part
line: c. 360

public function _header_join($txt, $item) {
if ($txt) { $txt.= Zend_Mime::LINEEND; }
if (is_array($item)) { $item = array_reduce($item, array($this, '_header_join'), ''); }
$txt .= $item;
return $txt;
}

switch ($format) {
case 'string':
if (!$header || (!count($header))){ $header = ''; } elseif (is_array($header)) { $header = array_reduce($header,
array($this, '_header_join'), ''); }
break;
case 'array':
$header = (array)$header;
default:
// do nothing
}




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 04/Dec/10 02:19 PM ]
Could you please supply a usecase that currently fails?
[ZF-9715] Mail is not working using Zend Mail Created: 20/Apr/10                             Updated: 16/Jul/10
Resolved: 16/Jul/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.10.3
Fix Version/s:          None

Type:                   Bug                                 Priority:               Major
Reporter:               Nagaraju kancherla                  Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:             Cannot Reproduce                    Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:          Zend_mail_smtp.txt

Description
Platform:
=========
Zend version:
Zend Framework Version: 1.10.3

PHP version:
PHP 5.2.4 (cli) (built: Aug 30 2007 07:06:31)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

Apche version:
2.0.58 on windows xp

Summary:
I am using Zend framework and trying to implement contact us form. The Zend_mail is failed to send a mail with
smtp.gmail.com. I tried with all possible options with ssl and with out SSL.

Finally i used PHPMailer from PEAR which i included in Zend/library, then mail is working fine.

Code with ZF which is failed to send a mail: [used correct user name and pwd)
=============================================
public function contactAction()
{
$this->view->paginaTitel = 'Contact';
$this->view->title = 'Contact us :]';

if( $this->_request->isPost() ) { require_once 'Zend/Mail.php'; require_once 'Zend/Mail/Transport/Smtp.php'; $config =
array('auth' => 'login', ' username' => 'iservechain', 'password' => 'iservechainpwd', 'port' => 465); /*$config =
array('auth' => 'login', 'username' => 'iservechain', 'password' => 'iservechainpwd', 'port' => 587, 'ssl' => 'ssl');*/
$transport = new Zend_Mail_Transport_Smtp('smtp.gmail.com', $config); Zend_Mail::setDefaultTransport($transport);
$mail = new Zend_Mail(); $mail->setFrom('iservechain@gmail.com', 'iservechain@gmail.com'); $mail-
>addTo('iservechain@gmail.com', 'iservechain@gmail.com'); $mail->setSubject('TestSubject'); $mail-
>setBodyText("This is the text of the mail."); $mail->send($transport); }
$this->render();

}

WORKING CODE WITH PHPMailer as a solution to the same issue:
===========================================================
public function contactAction()
{
//require_once 'Zend/Mail.php';
//require_once 'Zend/Mail/Transport/Smtp.php';

$this->view->paginaTitel = 'Contact';
$this->view->title = 'Contact us :]';

if( $this->_request->isPost() ) {
require_once('Zend/PHPMailer_v2.0.0/class.phpmailer.php');
require_once('Zend/PHPMailer_v2.0.0/class.smtp.php');
$mail=new PHPMailer();
$mail->IsSMTP();
$mail->SMTPAuth = true;
$mail->SMTPSecure = "ssl"; // sets the prefix to the servier
$mail->Host = "smtp.gmail.com"; // sets GMAIL as the SMTP server
$mail->Port = 465;
$mail->Username = "vrequal@gmail.com";
$mail->Password = "appletree";
$mail->FromName = 'vasanth';
$mail->From = "vasanthreddyb@hotmail.com";
$mail->Subject = "Test subject";
$mail->Body = "Test mail";

$mail->IsHTML(true);

$to = "iservechain@gmail.com";

$mail->AddAddress($to,$to); // To Address
echo '<pre>';
print_r($mail);

if(!$mail->Send()){ echo " Mailer Error: " . $mail->ErrorInfo; }

}
$this->render();
}

I would to know if any work around or any fix for this mailer issue.




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 16/Jul/10 02:51 PM ]
I couple of weeks ago I had zend_mail working with gmail, so it's not a bug. Maybe you did not use the correct
settings, or your ISP is blocking it. If you can't figure it out, I'd suggest you try the appropriate support channels like
mailinglists, irc or forums. Good luck!
[ZF-9714] _decodeLine() issue in Mail/Protocol/Imap.php Created: 19/Apr/10
Updated: 19/Apr/10
Status:                 Open
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.10.3
Fix Version/s:          None

Type:                   Bug                                   Priority:               Major
Reporter:               George Breahna                        Assignee:               Nico Edtinger
Resolution:             Unresolved                            Votes:                  1
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
With Dovecot IMAP server, some messages are not retrieved properly and eventually the connection times out
because ZF tries to read too many lines.

The problem is in the _decodeLine() function when ZF has to read a specific string length.
The server will reply with a line like this: * 767 FETCH (UID 19111 RFC822.TEXT {11825}

Where 11825 is the number of characters ZF has to read.

The problem is that somehow the internal mechanism for tracking the characters read ( strlen($token) ) reports for
some messages, the wrong count and this makes ZF ask for more lines using _nextLine() which eventually breaks
everything.

At first I thought this was an issue with Dovecot, but testing with other IMAP clients didn't result in any bug. There
must be something wrong in the way ZF reads and counts the data from the server.
[ZF-9630] add fetchBodyStructure to Zend_Mail_Protocol Created: 07/Apr/10
Updated: 09/Apr/10
Status:                 Open
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      None
Fix Version/s:          None

Type:                   New Feature                         Priority:               Major
Reporter:               Dominik Gehl                        Assignee:               Nico Edtinger
Resolution:             Unresolved                          Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
It would be nice to have an official access to FETCH BODYSTRUCTURE, including output parsing in
Zend_Mail_Protocol. This would make it so much more efficient to retrieve message overviews.

Currently, this can be achieved using requestAndResponse, but the output handling has then to be done 'by hand' ...




Comments
Comment by Dominik Gehl [ 07/Apr/10 09:04 AM ]
The following function allows to parse the output and to return an object similar to imap_fetchstructure

            static function parseStructure($structureArray) {

               $types =
array('text','multipart','message','application','audio','image','video');
               $encodings = array('7BIT','8BIT','BINARY','BASE64','QUOTED-
PRINTABLE');

               if (! is_array($structureArray[0])) {
                       $structureObj = new StdClass;
                       $structureObj->type = ((($pos =
array_search(strtolower($structureArray[0]), $types)) === false) ?
count($types) : $pos);
                       if ($structureArray[1] == 'NIL') {
                               $structureObj->ifsubtype = 0;
                       }
                       else {
                               $structureObj->ifsubtype = 1;
                               $structureObj->subtype = $structureArray[1];
                       }
                       if (! is_array($structureArray[2])) {
                               $structureObj->ifparameters = 0;
                       }
                       else {
                               $structureObj->ifparameters = 1;
                              $structureObj->parameters = array();
                              $i=0;
                              while ($i < count($structureArray[2])) {
                                      $parameterObj = new StdClass;
                                      $parameterObj->attribute =
$structureArray[2][$i];
                                      $i++;
                                      $parameterObj->value =
$structureArray[2][$i];
                                      $i++;
                                      $structureObj->parameters[] =
$parameterObj;
                              }
                      }
                      if ($structureArray[3] == 'NIL') {
                              $structureObj->ifid = 0;
                      }
                      else {
                              $structureObj->ifId = 1;
                              $structureObj->id = $structureArray[3];
                      }
                      if ($structureArray[4] == 'NIL') {
                              $structureObj->ifdescription = 0;
                      }
                      else {
                              $structureObj->ifdescription = 1;
                              $structureObj->description =
$structureArray[4];
                       }
                       $structureObj->encoding = ((($pos =
array_search(strtoupper($structureArray[5]), $encodings)) === false) ?
count($encodings) : $pos);
                       $structureObj->bytes = $structureArray[6];
                       if (($structureObj->type == 0) &&
isset($structureArray[7]) && ($structureArray[7] != 'NIL')) {
                               $structureObj->lines = $structureArray[7];
                       }
                       if (!isset($structureArray[8]) || ($structureArray[8]
== 'NIL')) {
                               $structureObj->ifdisposition = 0;
                               $structureObj->ifdparameters = 0;
                       }
                       else {
                               $structureObj->ifdisposition=1;
                               $structureObj->disposition =
$structureArray[8][0];
                               if (!isset($structureArray[8][1]) ||
!is_array($structureArray[8][1])) {
                                       $structureObj->ifdparameters = 0;
                               }
                               else {
                                       $structureObj->ifdparameters = 1;
                                       $structureObj->dparameters = array();
                                       $i=0;
                                       while ($i <
count($structureArray[8][1])) {
                                                  $parameterObj = new StdClass;
                                                  $parameterObj->attribute =
$structureArray[8][1][$i];
                                                  $i++;
                                                  $parameterObj->value =
$structureArray[8][1][$i];
                                                  $i++;
                                                  $structureObj->dparameters[] =
$parameterObj;
                                         }
                                 }
                          }
                          return $structureObj;
                 }
                 else {
                       $partsNb = 0;
                       $structureObj = new StdClass;
                       $structureObj->type = 1;
                       $structureObj->parts = array();
                       while (($partsNb<count($structureArray)) &&
(is_array($structureArray[$partsNb]))) {
                               $structureObj->parts[] =
self::parseStructure($structureArray[$partsNb]);
                               $partsNb++;
                       }
                       if ($structureArray[$partsNb] == 'NIL') {
                               $structureObj->ifsubtype = 0;
                       }
                       else {
                               $structureObj->ifsubtype = 1;
                               $structureObj->subtype =
$structureArray[$partsNb];
                       }
                       if (!isset($structureArray[$partsNb+1]) ||
($structureArray[$partsNb+1] == 'NIL')) {
                               $structureObj->ifparameters = 0;
                       }
                       else {
                               $structureObj->ifparameters = 1;
                               $structureObj->parameters = array();
                               $i=0;
                               while ($i < count($structureArray[$partsNb+1]))
{
                                       $parameterObj = new StdClass;
                                       $parameterObj->attribute =
$structureArray[$partsNb+1][$i];
                                       $i++;
                                       $parameterObj->value =
$structureArray[$partsNb+1][$i];
                                       $i++;
                                       $structureObj->parameters[] =
$parameterObj;
                               }
                       }
                       if (!isset($structureArray[$partsNb+2]) ||
($structureArray[$partsNb+2] == 'NIL')) {
                                              $structureObj->ifdisposition = 0;
                                              $structureObj->ifdparameters = 0;
                                  }
                                  else {
                               $structureObj->ifdisposition = 1;
                               $structureObj->disposition =
$structureArray[$partsNb+2][0];
                               if (!isset($structureArray[$partsNb+2][1]) ||
!is_array($structureArray[$partsNb+2][1])) {
                                       $structureObj->ifdparameters = 0;
                               }
                               else {
                                       $structureObj->ifdparameters = 1;
                                       $structureObj->dparameters = array();
                                       $i=0;
                                       while ($i <
count($structureArray[$partsNb+2][1])) {
                                               $parameterObj = new StdClass;
                                               $parameterObj->attribute =
$structureArray[$partsNb+2][1][$i];
                                               $i++;
                                               $parameterObj->value =
$structureArray[$partsNb+2][1][$i];
                                               $i++;
                                               $structureObj->dparameters[] =
$parameterObj;
                                       }
                               }
                       }
                       return $structureObj;

                       }
           }
Comment by Nico Edtinger [ 09/Apr/10 09:07 AM ]
Actually Zend_Mail_Part has a recursive iterator that can be, among other things, used to retrieve the structure of a
message. That doesn't mean FETCH BODYSTRUCTURE doesn't make sense, but I think it might be a good idea to
create Zend_Mail_Part_Imap and have it prefetch the structure when a Zend_Mail_Message_Imap is returned in
getMessage(). The benefit is having the same interface as in all other storage classes and an object that's ready to
use if you find a part in the structure that you want to do something with (like fetching it's content/body).
[ZF-9585] fifth parameter of php mail() function used with an empty
string in Zend_Mail_Transport_Sendmail Created: 01/Apr/10 Updated: 01/Apr/10 Resolved:
01/Apr/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Application_Resource, Zend_Mail
Affects Version/s:       1.10.2
Fix Version/s:           None

Type:                    Bug                                  Priority:                Minor
Reporter:                Jean-Marie Lamodière                 Assignee:                Dolf Schimmel (Freeaqingme)
Resolution:              Won't Fix                            Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
When using
resources.mail.transport.type = sendmail
in application.ini , Zend_Mail_Transport_Sendmail::_sendMail() detects $this->parameters as en empty string instead
of null, (line 101). So, php mail() function is used with a fifth parameter (line 126) that contains an empty string. It's a
problem as this fifth parameter seems to be forbiden in safe mode.

A workaround is not to use resources.mail.transport.type = sendmail in application.ini as sendmail is the default
transport anyway.

Thanks




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 01/Apr/10 07:28 AM ]
Please note that using sendmail is not advised in real applications, and that the SMTP adapter is much better to use.

As to what the issue itself is concerned; after a short confabulation on IRC we decided not to fix this issue for the
simple reason that we don't want to start writing work-arounds throughout the entire framework in order to support
unsupported installations. If we started doing so, the next person wants us to support php5.1 and within a couple of
weeks we'll be flooded with questions to please do support php4, and if we wait long enough, I'm pretty sure some
people will start wondering why we can't support php3 just as well.

Using Safe Mode really is a bad behavior since it is security through obscurity (hence it's been officially deprecated
as of php5.3, and will be removed as of php6). Therefore, I'd like you to advise to switch hosts, and if that's not
possible, just stick with the smtp adapter.
[ZF-9582] Maybe it could be possible, to access the unexpected status
code found in Zend_Mail_Protocol_Abstract::_expect() Created: 31/Mar/10 Updated:
27/Apr/10 Resolved: 15/Apr/10
Status:                   Resolved
Project:                  Zend Framework
Component/s:              Zend_Mail
Affects Version/s:        1.10.1
Fix Version/s:            None

Type:                     New Feature                       Priority:              Major
Reporter:                 Eutychus                          Assignee:              Satoru Yoshida
Resolution:               Won't Fix                         Votes:                 0
Remaining Estimate: Not Specified
Time Spent:               Not Specified
Original Estimate:        Not Specified


Description
Maybe it could be possible, to access the unexpected status code found in Zend_Mail_Protocol_Abstract::_expect() it
could be a good idea to return it via Zend_Mail_Protocol_Exception as a code parameter ...




Comments
Comment by Satoru Yoshida [ 01/Apr/10 12:45 AM ]
Hello, Eutychus. I have changed that _expect() method recently, so I will be happy if You try new version 1.10.3 .
Comment by Eutychus [ 01/Apr/10 09:16 AM ]
???

Maybe I am blind ...

If I look at the current _expect() of the trunk I find:

           /**

                    Parse server response for successful codes
                     *
                    Read the response from the stream and check for expected return code.
                    Throws a Zend_Mail_Protocol_Exception if an unexpected code is returned.
                     *
                    @param string|array $code One or more codes that indicate a successful response
                    @throws Zend_Mail_Protocol_Exception
                    @return string Last line of response string
                     */
                     protected function _expect($code, $timeout = null)
                     {
                     $this->_response = array();
                     $cmd = '';
                     $more = '';
                     $msg = '';
                   $errMsg = '';

         if (!is_array($code))

         Unknown macro: { $code = array($code); }

         do {
         $this->_response[] = $result = $this->_receive($timeout);
         list($cmd, $more, $msg) = preg_split('/([\s-]+)/', $result, 2, PREG_SPLIT_DELIM_CAPTURE);

         if ($errMsg !== '')

         Unknown macro: { $errMsg .= ' ' . $msg; }
         elseif ($cmd === null || !in_array($cmd, $code))
         Unknown macro: { $errMsg = $msg; }

         } while (strpos($more, '' message prefix indicates an information string instead of a response string.

         if ($errMsg !== '')

         Unknown macro: { /** * @see Zend_Mail_Protocol_Exception */ require_once
         'Zend/Mail/Protocol/Exception.php'; throw new Zend_Mail_Protocol_Exception($errMsg); }

         return $msg;
         }

The code returned by for example an SMTP Server is passed to Zend_Mail_Protocol_Exception.
Comment by Eutychus [ 01/Apr/10 09:19 AM ]
Fu**

what happended to my quotation??

Whatever ...

The call of "throw new Zend_Mail_Protocol_Exception($errMsg);" does not seem to me that there the for example
Smtp Server result is passed to the Exception ...
Comment by Satoru Yoshida [ 15/Apr/10 11:14 PM ]
Sorry, sadly, I can not understand difference between current output and the result that you expect it.
Comment by Eutychus [ 27/Apr/10 03:34 AM ]
Maybe there is a missunderstanding on my side ... is there a way to receive the smtp status code if an email isn't
property submitted?
[ZF-9505] Zend_Mail_Protocol_Abstract - truncates server response
when SMTP server responds with a message containing spaces Created:
22/Mar/10 Updated: 13/Apr/10 Resolved: 24/Mar/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.10.2
Fix Version/s:           1.10.3

Type:                    Bug                                 Priority:               Major
Reporter:                Alex                                Assignee:               Satoru Yoshida
Resolution:              Fixed                               Votes:                  0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Issue Links:             Related
                         is related to   ZF-9299     Zend_Mail server response error messa...               Resolved

Description
When server response message contains spaces only the first "word" is retrieved.

Sample response to reproduce:
535 5.7.0 authentication failed

Expected error message: 5.7.0 authentication failed
Actual error message: 5.7.0

The reason is using of string template for parsing server responses using sscanf (default: 3 digit code and response
string) - '%d%s'. So, the function parses the response until the first space character is encountered.




Comments
Comment by Satoru Yoshida [ 24/Mar/10 08:25 AM ]
Thank You for report, solved SVN r21634.
Comment by Jeff Clark [ 12/Apr/10 12:06 PM ]
Perhaps this deprecation is unnecessary. Wouldn't the follow work just as well?

— Mail/Protocol/Abstract.php (revision 21842)
+++ Mail/Protocol/Abstract.php (working copy)
@@ -107,7 +107,7 @@

          String template for parsing server responses using sscanf (default: 3 digit code and response string)
          @var resource
           */

          protected $_template = '%d%s';
           + protected $_template = '%d %[^$]s';
/**
Comment by Alex [ 12/Apr/10 11:12 PM ]
2 Jeff Clark
Using '%d %[^$]s' doesn't cover cases when response contains hyphen after code (e.g 220-OK) used for multi-line
responses.
Comment by Satoru Yoshida [ 13/Apr/10 06:33 AM ]
Thank You, Jeff and Alex.

Zend_Mail_Protocol_Abstract should be able to handle multi-line SMTP response like as specified in .

So, The change of SVN r21634 would be better rather than modifing only $_template.
[ZF-9486] zend_mail_transport_sendmail::_sendMail() missing
restore_error_handler() on exit path Created: 19/Mar/10 Updated: 22/Mar/10 Resolved: 22/Mar/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.10.2
Fix Version/s:          1.10.3

Type:                   Patch                                Priority:                Minor
Reporter:               John Crenshaw                        Assignee:                Satoru Yoshida
Resolution:             Fixed                                Votes:                   1
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
In Zend_Mail_Transport_Sendmail::_sendMail() there is a minor bug. If the first error is thrown,
restore_error_handler() is never called, therefore 'leaking' the previously set '_handleMailErrors' handler, and
corrupting the handler stack. Solution is to add a call to restore_error_handler() before throwing, or else refactor the
code to prevent the unexpected exit path.

See code below for a sample fix:

zend_mail_transport_sendmail::_sendMail()
public function _sendMail()
    {
        set_error_handler(array($this, '_handleMailErrors'));
        if ($this->parameters === null) {
            $result = mail(
                 $this->recipients,
                 $this->_mail->getSubject(),
                 $this->body,
                 $this->header);
        } else {
               if(!is_string($this->parameters)) {
                     /**
                      * @see Zend_Mail_Transport_Exception
                      *
                      * Exception is thrown here because
                      * $parameters is a public property
                      */

                         // FIX: set_error_handler was called earlier, we need to
                         // reverse that before returning.
                         restore_error_handler();

                        require_once 'Zend/Mail/Transport/Exception.php';
                        throw new Zend_Mail_Transport_Exception(
                            'Parameters were set but are not a string'
                        );
                       }
                 $result = mail(
                     $this->recipients,
                     $this->_mail->getSubject(),
                     $this->body,
                     $this->header,
                     $this->parameters);
           }
           restore_error_handler();

        if ($this->_errstr !== null || !$result) {
            /**
             * @see Zend_Mail_Transport_Exception
             */
            require_once 'Zend/Mail/Transport/Exception.php';
            throw new Zend_Mail_Transport_Exception('Unable to send mail. ' .
$this->_errstr);
        }
    }


Comments
Comment by Satoru Yoshida [ 22/Mar/10 05:53 AM ]
Thank You for report, John. Solved at SVN r21603
[ZF-9483] Zend_Mail charset configuration Created: 19/Mar/10                           Updated: 02/Dec/10
Status:                Open
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     1.10.2
Fix Version/s:         Next Major Release

Type:                  Coding Standards Violation          Priority:               Minor
Reporter:              Renan de Lima                       Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:            Unresolved                          Votes:                  1
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified

File Attachments:          Zend_Mail.patch        Zend_Mail_MailTest.patch
Issue Links:           Related
                       is related to    ZF-4955     Have zend_mail support instantiation ...             Resolved

Description
Zend_Mail constructor sets charset value from passed argument. This is not a problem, but there is no way to set it
after you have an object of this class, there is no a setCharset(), but it still is not a problem.

The constructor has one argument, this one has as default value "iso-8859-1", it does not look good. The construct
method also makes hard to extends the class and to overwrite it, once this not follow the code standard, users must
send default charset encoding to parent constructor.

http://framework.zend.com/wiki/display/ZFDEV/PHP+Coding+Standard+%28draft%29#PHPCodingStandard%28draft
%29-OptionalParameters

Sample

class My_Mail extends Zend_Mail
{
    public function __construct()
    {
        // do something...
    }
}

$mail = new My_Mail();

or

class My_Mail extends Zend_Mail
{
    public function __construct($charset = null)
    {
        // do something...
        parent::__construct($charset);
    }
}
$mail = new My_Mail();

Expected result

$mail->_charset; // "iso-8859-1"

Actual result

$mail->_charset; // null


Comments
Comment by Renan de Lima [ 19/Mar/10 12:22 PM ]
attached is test file and Zend_Mail class with changes: default value for $_charset attribute, default value of
constructor argument and setCharset() method (ps: i haven't run the test)
Comment by Satoru Yoshida [ 09/Jun/10 12:30 AM ]
Sorry, I have been inactive since last April.
Comment by Dolf Schimmel (Freeaqingme) [ 19/Jun/10 06:39 PM ]
Reopening because tests have not been applied yet. Also; this will not be released in a mini release because this in
specific circumstances may be a BC break
Comment by Benoît Durand [ 19/Sep/10 05:15 AM ]
Why Renan has applied only modifications about constructor without add the setCharset method?
Comment by Renan de Lima [ 19/Sep/10 07:42 AM ]
Benoit, Freeaqingme has assign this issue to himself to fix something. Actually the issue is about constructor
problem, anyway i think we should add setCharset() to Zend_Mail class.

There are some issues that could be affected, see

+1 for adding setCharset()
Comment by Dolf Schimmel (Freeaqingme) [ 19/Sep/10 11:12 AM ]
Issue will be implemented with ZF2. Kinda impossible with current architecture.
[ZF-9299] Zend_Mail server response error messages garbled Created: 01/Mar/10
Updated: 24/Mar/10 Resolved: 24/Mar/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.10.0
Fix Version/s:          1.10.3

Type:                   Bug                                   Priority:               Major
Reporter:               monk e boy                            Assignee:               Satoru Yoshida
Resolution:             Fixed                                 Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Related
                        is related to    ZF-9505      Zend_Mail_Protocol_Abstract - truncat...         Resolved

Description
The error message from Zend_Mail (as an exception message) reported as:

Command

Actual error message from server:

502 Command not implemented

Zend_Mail error message:

Access

Expected error message:

530 Access denied

If this is intentional, then maybe the documentation is incorrect as there is no mention of this.




Comments
Comment by Satoru Yoshida [ 01/Mar/10 07:37 PM ]
I will be happy if you would provide reproduce code.
Comment by Satoru Yoshida [ 24/Mar/10 08:29 AM ]
Thank You for report, Solved by , at SVN r21634.
[ZF-9262] Multipart mail Content-Transfer-Encoding: quoted-printable
not conform to RFC 1521 Created: 25/Feb/10 Updated: 06/Dec/10 Resolved: 06/Dec/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.10.2
Fix Version/s:           Next Major Release

Type:                    Bug                               Priority:               Major
Reporter:                PERIDONT                          Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:              Fixed                             Votes:                  0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Issue Links:             Related
                         is related to   ZF-10130    Zend_Mail sets wrong Content-Transfer...          Resolved

Description
Hello,

Hi get some probleme with multipart email message rejected by mailinblack v4 smtp.
Mail are rejected due to non conform header.
The line "Content-Transfer-Encoding: quoted-printable" in the body header seems to be non conform.

Header seams not conforme to RFC 1521 section 5 if i well understand it :

           Certain Content-Transfer-Encoding values may only be used on certain
           Content-Types. In particular, it is expressly forbidden to use any
           encodings other than "7bit", "8bit", or "binary" with any Content-
           Type that recursively includes other Content-Type fields, notably the
           "multipart" and "message" Content-Types. All encodings that are
           desired for bodies of type multipart or message must be done at the
           innermost level, by encoding the actual body that needs to be
           encoded.

Here is the code to forge the mail :

$htmlPart = new Zend_Mime_Part($html);
$htmlPart->type = Zend_Mime::TYPE_HTML;
$mail = new Zend_Mail();
$mail->setType(Zend_Mime::MULTIPART_ALTERNATIVE);
$mail->addTo($email);
$mail->setBodyText($mailText);
$mail->addPart($htmlPart);
$mail->setFrom($from);
$mail->setSubject($subjet);
$mail->setReplyTo($reply);
$mail->setReturnPath($newsletter->reply);
$mail->send();
Here is the header of the mail generated :

Content-Transfer-Encoding: quoted-printable
Content-Type: multipart/alternative; charset="iso-8859-1";
 boundary="=_5ab7641877166ea4b68a25d0a93c0d27"
Content-Disposition: inline
MIME-Version: 1.0
Message-Id: <20100224115611.E612423C258@xxxxx>

This is a message in Mime Format.                     If you see this, your mail reader does not
support this format.

--=_5ab7641877166ea4b68a25d0a93c0d27
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


--=_5ab7641877166ea4b68a25d0a93c0d27
Content-Type: multipart/related;
 boundary="=_e9b4af800ad902f599cd820839f1e83d"
Content-Transfer-Encoding: 8bit

This is a message in Mime Format.                     If you see this, your mail reader does not
support this format.

--=_e9b4af800ad902f599cd820839f1e83d
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Regards,

Nicolas PERIDONT




Comments
Comment by Satoru Yoshida [ 12/Jun/10 06:20 AM ]
Sorry, I have been inactive since last April.
Comment by Andreas F. [ 10/Jul/10 03:19 AM ]
after created the other issue I found out these two issues report the same error. the other issue includes a bugfix.
Comment by Dolf Schimmel (Freeaqingme) [ 06/Dec/10 03:24 AM ]
Fixed in ZF2.
[ZF-9095] Defaultencoding for Mails should be
Zend_Mime::ENCODING_BASE64 Created: 05/Feb/10 Updated: 28/Feb/10                              Resolved: 28/Feb/10
Status:                    Resolved
Project:                   Zend Framework
Component/s:               Zend_Mail
Affects Version/s:         1.10.0
Fix Version/s:             None

Type:                      Improvement                      Priority:               Major
Reporter:                  Zoran Zaric                      Assignee:               Satoru Yoshida
Resolution:                Not an Issue                     Votes:                  0
Remaining Estimate: Not Specified
Time Spent:                Not Specified
Original Estimate:         Not Specified


Description
The documentation says "The default behavior of Zend_Mail is to assume the attachment is a binary object
(application/octet-stream), that it should be transferred with base64 encoding, and that it is handled as an
attachment." http://framework.zend.com/manual/en/zend.mail.attachments.html

But this isn't the case.




Comments
Comment by Ramon Henrique Ornelas [ 05/Feb/10 08:23 AM ]
Reassigned Satoru Yoshida
Comment by Satoru Yoshida [ 28/Feb/10 03:39 AM ]
I think it is not an issue , because default value of 2nd and 4th parameter in createAttachment() are
Zend_Mime::TYPE_OCTETSTREAM and Zend_Mime::ENCODING_BASE64 .
[ZF-9094] Binary attachments in examples encoded with
Zend_Mime::ENCODING_8BIT Created: 05/Feb/10 Updated: 28/Feb/10 Resolved: 28/Feb/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.10.0
Fix Version/s:           1.10.3

Type:                    Docs: Problem                     Priority:           Minor
Reporter:                Zoran Zaric                       Assignee:           Satoru Yoshida
Resolution:              Fixed                             Votes:              0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Language:                English

Description
On http://framework.zend.com/manual/en/zend.mail.attachments.html the examples don't work, the images are
encoded with Zend_Mime::ENCODING_8BIT, which breakes them, Zend_Mime::ENCODING_BASE64 should be
used (as the text says).




Comments
Comment by Ramon Henrique Ornelas [ 05/Feb/10 08:20 AM ]
Reassigned Satoru Yoshida
Comment by Satoru Yoshida [ 05/Feb/10 06:22 PM ]

Ok, Ramon, I'll see it
Comment by Ramon Henrique Ornelas [ 06/Feb/10 06:09 AM ]

Thank you Satoru assigned the you, because I see you involved in issues Zend_Mail      .
Comment by Satoru Yoshida [ 28/Feb/10 03:28 AM ]
Thank You for report, Solved at SVN r21230
[ZF-9070] Zend_Mail::_filterEmail() invalidates some addresses Created:
03/Feb/10 Updated: 16/Dec/10
Status:                  Open
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.7.3, 1.7.4, 1.7.5, 1.7.6, 1.7.7, 1.7.8, 1.7.9, 1.8.0, 1.8.1, 1.8.2, 1.8.3, 1.8.4, 1.8.5, 1.9.0, 1.9.1,
                         1.9.2, 1.9.3, 1.9.4, 1.9.5, 1.9.6, 1.9.7, 1.10.0
Fix Version/s:           None

Type:                    Bug                                    Priority:                 Minor
Reporter:                Chris Buckley                          Assignee:                 Dolf Schimmel (Freeaqingme)
Resolution:              Unresolved                             Votes:                    1
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

File Attachments:           ZF-9070

Description
Zend_Mail::_filterEmail() strips out double quotes from e-mail addresses, but this invalidates certain addresses (i.e.
ones where the local part contains control characters) causing errors further down the line.

http://tools.ietf.org/html/rfc3696#page-6

So (for instance) if a recipient "abc@def"@example.com is added, the quotes are stripped but the @ in the local part
is not escaped with a backslash and so the address becomes invalid. I imagine the same would happen with a
number of other control characters.




Comments
Comment by Sebastian Heise [ 22/Mar/10 01:37 AM ]
For further reading:
http://groups.google.com/group/eaut/web/rules-for-valid-email-addresses?pli=1
and
http://www.remote.org/jochen/mail/info/chars.html

My problem is an email address like "Mr.O'Reilley@example.com". The problem is the single quote.
This address gives the following error: "511 sorry, recipient address has invalid format (#5.1.1 - chkuser)" - which is
incorrect, becaue it is a valid email address.
Comment by Sebastian Heise [ 31/Mar/10 02:23 PM ]
We've already quite a few of those addresses signed up now - and that's just the closed-beta phase without being
live.
I hope for a fix rather soon.

Any suggestions on how I can do a hot-fix/hack until it's officially fixed?
Comment by Sebastian Heise [ 31/Mar/10 02:47 PM ]
After further investigation, it probably is more likely to be an issue in Zend_Mail_Protocol_Smtp->rcpt();
Comment by Sebastian Heise [ 31/Mar/10 04:41 PM ]
Apologies guys!
Turns out that the SMTP Server doesn't accept the message! FZ seems not to be at fault.
Comment by Satoru Yoshida [ 26/May/10 08:54 PM ]
Thank You for Your report, Sebastian.
Sorry for late responce .


I will feel happy if You tell me whether this issue is still active or not.
Comment by Sebastian Heise [ 26/May/10 09:03 PM ]
I can't speak for Chris and his initial issue, since I didn't test that.
The issue I was having turned out to be not related to this. Sorry for any confusion caused.
Comment by Chris Buckley [ 27/May/10 03:56 AM ]
Yep, the issue is still active.

Ideally _filterEmail() shouldn't remove content; it should quote or backslash escape if it finds special characters. For
instance, a comma is perfectly valid in "foo,bar"@example.com or foo\,bar@example.com.

I guess one difficulty is detecting whether a valid (pre-filtered) e-mail address has been provided, or whether it needs
to be filtered.
Comment by Satoru Yoshida [ 12/Jun/10 06:49 AM ]
Sorry, I have been busy in another work and inactive here since last April.
Comment by Oleg Lobach [ 19/Nov/10 03:05 AM ]
Here is patch to solve problem with double quoted local part
Comment by Oleg Lobach [ 19/Nov/10 03:06 AM ]
Check my patch, plz
Comment by Satoru Yoshida [ 19/Nov/10 08:59 PM ]
Oleg, Sorry to say that I am in inactive for component fixes.

Because sadly, document modifications eat up my time.
There are too many modifications in document since last winter.
Comment by Oleg Lobach [ 20/Nov/10 02:43 AM ]
Check my patch plz
[ZF-9042] Zend_Mail_Transport_Sendmail::$parameters should not be
public. Created: 01/Feb/10 Updated: 06/Dec/10 Resolved: 06/Dec/10
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     Next Major Release
Fix Version/s:         Next Major Release

Type:                  Improvement                      Priority:   Minor
Reporter:              Dolf Schimmel (Freeaqingme)      Assignee:   Dolf Schimmel (Freeaqingme)
Resolution:            Fixed                            Votes:      0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified


Comments
Comment by Dolf Schimmel (Freeaqingme) [ 06/Dec/10 03:36 AM ]
Resolved with setOptions() as should be.
[ZF-9011] Unable to set additional parameters for Sendmail transport
when using mail application resource Created: 29/Jan/10 Updated: 02/Feb/11 Resolved: 30/Jan/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Application_Resource, Zend_Mail
Affects Version/s:       1.10.0
Fix Version/s:           1.10.1

Type:                    Bug                                 Priority:                Minor
Reporter:                Matt Cockayne                       Assignee:                Dolf Schimmel (Freeaqingme)
Resolution:              Fixed                               Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

File Attachments:           Zend_Mail_Transport_Sendmail.diff
Issue Links:             Duplicate
                         duplicates          ZF-9034      Mail resource creates SMTP transport ...           Closed
                         is duplicated by    ZF-9033      Unable to configure sendmail transpor...           Resolved
                         Related
                         is related to       ZF-5337      Transport_Smtp constructor should all...           Resolved
                         is related to       ZF-11022     Setting resources.mail.transport.regi...           Open

Description
When Implementing the Zend_Application_Resouce_Mail for use with sendmail the transport class has no way to
correctly accept and additionalParameters

I have modified my version to suit my needs by altering the constructor of the transport class to identify the
parameters as an array and treat them accordingly

patch attached

this will allow the use of application configs such as

; Relevant
resources.mail.transport.type = sendmail
resources.mail.transport.envelope = "-tjohn@example.com"

; Irrelevant
resources.mail.defaultFrom.email = john@example.com
resources.mail.defaultFrom.name = "John Doe"
resources.mail.defaultReplyTo.email = Jane@example.com
resources.mail.defaultReplyTo.name = "Jane Doe"


Comments
Comment by Dolf Schimmel (Freeaqingme) [ 30/Jan/10 06:38 PM ]
Thank you for reporting this issue. Will be released in the next minor release, possibly earlier.
Comment by Dolf Schimmel (Freeaqingme) [ 01/Feb/10 11:41 AM ]
Will be released next mini release.
[ZF-8988] Zend Mail Transport SMTP set sender email address Created:
28/Jan/10 Updated: 25/Nov/10 Resolved: 22/Nov/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.11.0
Fix Version/s:          1.11.1

Type:                   Bug                                  Priority:                Blocker
Reporter:               Stefan Straakenbroek                 Assignee:                Marc Hodgins
Resolution:             Fixed                                Votes:                   4
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:           ZF-8988.patch
Issue Links:            Dependency
                        depends on              ZF-7008     Method setReturnPath() not working               Resolved
                        Duplicate
                        is duplicated by        ZF-10528    Zend Mail not setting return path                Resolved

Description
File: /Zend/Mail/Transport/Smtp.php
Line: 207

In the smtp transport the from address is set with the following function:

// Set sender email address
$this->_connection->mail($this->_mail->getFrom());

When sending a mail to an unknown user with a valid host. In most cased the headers will be read and the Return-
Path header will be used to return the mail.

When sending a mail to a non-existing host. The smtp server will return the mail to the from address given in the smpt
transport. The header has not been read.

In my opinion the sender email address must be set with the following function, so the bounce addresses goes to the
return path.

// Set sender email address
$this->_connection->mail($this->_mail->getReturnPath());

Which automatically fallback in the from address if return path is not set.




Comments
Comment by Ilan Rivers [ 29/Jan/10 01:40 AM ]
Funny that this was created yesterday. I recently had the same problem on a project I am working on. This should
really be as simple as changing the function that is called. Hope that this fix can be included in the next mini release.
Comment by Stefan Straakenbroek [ 01/Feb/10 01:03 AM ]
I saw the issue but that one is using the php mail function:

"Sending mail with an additional command line parameter."

In my case i use the SMTP transport.

$transport = new Zend_Mail_Transport_Smtp('mail.example.com');

Because of that, i cannot use the function described in zend manual:

$transport = new Zend_Mail_Transport_Sendmail('-freturn_to_me@example.com');
Comment by Andy Thompson [ 27/Mar/10 06:26 AM ]
I also agree that the MAIL FROM should be able to be overridable (either as a transport option or by interpretting the
$mail->getReturnPath).

This is commonly used to forward bounces to another email address for processing, whilst allowing manually replied
messages go back to the From address.

The Reply-To header isn't an option in these cases, as the bounce address might have additional information such as
user id to be used to identify the non-existant email address for automatic unsubscription, and unnessary for the
receiver to see the information (which clients seeing Reply-To, will also display the From).

Since sendmail supports setting this return path, please can the smtp class?
Comment by Andy Thompson [ 28/Mar/10 01:11 PM ]
Please read http://www.ietf.org/rfc/rfc2821.txt   regarding Return-Path

# originally added this feature

# was incorrect, it was not a bug, and was what broke # and caused this issue.

The Return-Path is what is set in transit by the MAIL FROM, and any Return-Path header sent to Smtp is stripped.
The From mail header gives the user the friendly reply address even when MAIL FROM is different.
Comment by Andy Thompson [ 28/Apr/10 01:40 PM ]
To clarify, I believe this is a regression bug caused by breaking Smtp Return-Path support, affecting ZF 1.9.6
onwards. (edited to correct version number)

Here is a patch to fix it.
Comment by Andy Thompson [ 28/Apr/10 03:17 PM ]
I was asked on irc to include a unit test for this, so I've added a test to the SmtpTest, and included a mock SMTP
protocol class needed for it, which fails before the patch and succeeds after.
Comment by Satoru Yoshida [ 09/Jun/10 12:24 AM ]
Sorry, I have been inactive since last April.
Comment by Marc Hodgins [ 06/Nov/10 02:39 AM ]
Agreed, the behavior introduced by is incorrect. The RFC 2821 states that both the MAIL FROM and the Return-Path
header should be the same value:

The first step in the procedure is the MAIL command.

          MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
... and ...

 The time stamp line and the return path line are formally defined as
   follows:

Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>

Andy, there are a couple of problems with your proposed patch. It doesn't run unless the
TESTS_ZEND_MAIL_SMTP_ENABLED constant is set to true, which isn't necessary because this can be tested
offline. Also the calls to addBcc(), addCc(), etc, aren't necessary to test this.

So, I'm attaching a simplified patch which includes a test that runs by default.
Comment by Marc Hodgins [ 22/Nov/10 02:52 PM ]
Applied to trunk in r23423, merged to 1.11 release branch in r23424
[ZF-8981] Zend_Application_Resource_Mail and registering default
transport with ini file Created: 27/Jan/10 Updated: 01/Feb/10 Resolved: 01/Feb/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Application_Resource, Zend_Mail, Zend_Mail_Storage
Affects Version/s:       1.10.0
Fix Version/s:           1.10.1

Type:                    Bug                                   Priority:                   Trivial
Reporter:                Marko Korhonen                        Assignee:                   Dolf Schimmel (Freeaqingme)
Resolution:              Fixed                                 Votes:                      0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
Hi,

When using new Mail resource and ini files and register option for Zend_Transport:

resources.mail.transport.register = true // does not work, as it is converted to (int) 1

but as string it works:
resources.mail.transport.register = "true"

In Zend_Application_Resource_Mail and in method getMail()
there is following code:

if(!isset($options['transport']['register']) ||
                   (isset($options['transport']['register']) &&
                        !is_numeric($options['transport']['register']) &&
                        (bool) $options['transport']['register'] == true))
                {
                    Zend_Mail::setDefaultTransport($this->_transport);
                }

br, Marko




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 01/Feb/10 12:02 PM ]
Resolved issue, thank you for reporting.
[ZF-8873] improvement in classes Zend_Mail_Transport Created: 19/Jan/10                                  Updated:
06/Dec/10 Resolved: 06/Dec/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.10.0
Fix Version/s:          Next Major Release

Type:                   Improvement                      Priority:             Major
Reporter:               Ramon Henrique Ornelas           Assignee:             Dolf Schimmel (Freeaqingme)
Resolution:             Fixed                            Votes:                0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:           Zend_Mail_Transport.patch

Description
In the classes Zend_Mail_Transport_Sendmail and Zend_Mail_Transport_Smtp
renamed method _sendMail() to sendMail(), compatibility keeping.

added Fluent Interface in Zend_Mail_Transport_Smtp::setConnection().

configuration made in Zend_Mail_Transport_Smtp::_sendMail() been
created a protected method responsible by configuration. called Zend_Mail_Transport_Smtp::setDefaultConnection().




Comments
Comment by Satoru Yoshida [ 28/Feb/10 01:48 AM ]
Up priority for development-2.0
Comment by Satoru Yoshida [ 09/Jun/10 12:23 AM ]
Sorry, I have been inactive since last April.
Comment by Benoît Durand [ 19/Sep/10 01:14 AM ]
Why wait for ZF2 and not the next minor release?
Comment by Dolf Schimmel (Freeaqingme) [ 06/Dec/10 02:24 AM ]
Resolved in ZF2
[ZF-8723] addBcc() and addCc() also add email addresses to the "To"
header Created: 06/Jan/10 Updated: 07/Feb/11
Status:                 Open
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.9.3
Fix Version/s:          Next Major Release

Type:                   Docs: Task                         Priority:               Trivial
Reporter:               Jan Olsen                          Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:             Unresolved                         Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
I have the following simple code:

$mail = new Zend_Mail();}}
$mail->setBodyText('This is the text of the mail.');
$mail->setFrom('somebody@example.com', 'Some Sender');
$mail->addTo('jan.olsen@example.com');
$mail->addBcc('janpolsen@example.com'); //notice a different email address
$mail->setSubject('TestSubject');
$mail->send();

When I run this code, I will receive an email with BOTH jan.olsen@example.com and
janpolsen@example.com in the TO field. That is very very very unfortunate, because it will expose email
addresses when it shouldn't     .

The same happens if I use addCc().

As I see it, then the only possible way to send mails to people using BCC is by tricking addHeader() to accept
"Bcc".

Back in 2007 "mike55" wrote about this issue (http://www.mail-archive.com/fw-
general@lists.zend.com/msg06988.html ), but it seems that the problem is still there.

PS: This is only tested on ZF v1.9.3PL1, but I can't see any fixes/changes regarding this in the changelogs from
v1.9.3 through v1.9.6.




Comments
Comment by Mickael Perraud [ 06/Jan/10 05:30 AM ]
Sendmail Transport and Windows?

If yes =>
"As the PHP manual states the mail() function has different behaviour on Windows and on *nix based systems. Using
the Sendmail Transport on Windows will not work in combination with addBcc(). The mail() function will sent to the
BCC recipient such that all the other recipients can see him as recipient!

Therefore if you want to use BCC on a windows server, use the SMTP transport for sending!"

Extract of the new documentation for ZF 1.10
Comment by Jan Olsen [ 06/Jan/10 05:42 AM ]

Thanks for the super fast response

Windows... check
Sendmail Transport... check (it's the default which I can read is Zend_Mail_Transport_Sendmail

So it's a PHP "bug"?

How come I can add:
$mail->addHeader("Bcc: janpolsen@example.com\r\n", null);
... which will work without exposing the email address?

I will try to see if I can change the Transport method.
Comment by Jan Olsen [ 06/Jan/10 06:05 AM ]
It does indeed seem to work if I use:

$tr1 = new Zend_Mail_Transport_Smtp('exchange.example.com');

$mail = new Zend_Mail();
...
$mail->send($tr1);

I do however find it a bit weird, when I can use the addHeader()-trick.
Comment by Dolf Schimmel (Freeaqingme) [ 06/Jan/10 06:08 AM ]
In that case someone else will have to resolve this issue, since I only have linux and can't test on windows.
Comment by Satoru Yoshida [ 09/Jun/10 12:22 AM ]
Sorry, I have been inactive since last April.
Comment by Dolf Schimmel (Freeaqingme) [ 16/Jul/10 02:53 PM ]
If it doesn't work it is not supported. You're probably best off reporting this bug to the php bugtracker if there isn't a
bugreport already. I'm postponing this issue so that if Zend\Mail (zf2) doesn't support it either (which I'm not
expecting), we can test it again and add a nice disclaimer in the documentation.

Thank you for taking the time to report this issue.
Comment by Dolf Schimmel (Freeaqingme) [ 17/Jul/10 07:13 AM ]
Leaving this issue open to make sure it gets documented with zf2
Comment by Martin Keckeis [ 07/Feb/11 06:14 AM ]
I've got the same problem here.

The problem is here (Zend/Mail/Transport/Sendmail.php):

$result = mail(
    $this->recipients, //contain all addresses from to, cc and bcc (should
only contain "to")
    $this->_mail->getSubject(),
    $this->body,
    $this->header //contain all headers with cc, bcc (and not to -> like it
should be)
);

The "to" can also be empty, if only using "bcc"

My patchfor now:

public function _sendMail()
     {
         if ($this->parameters === null) {
+
+              $recipients = $this->_mail->getHeaders();
+              if(isset($recipients['To']))
+                      $toMail = $this->recipients['To'];
+              else
+                      $toMail = '';
+
             set_error_handler(array($this, '_handleMailErrors'));
             $result = mail(
-                $this->recipients,
+                $toMail,
                 $this->_mail->getSubject(),
                 $this->body,
                 $this->header);
[ZF-8577] Message-ID is set not valid according to RFC 2822 Created: 18/Dec/09
Updated: 31/Jan/10 Resolved: 31/Jan/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.9.3
Fix Version/s:           1.10.1

Type:                    Bug                                   Priority:                Minor
Reporter:                Henrik Olsen                          Assignee:                Satoru Yoshida
Resolution:              Fixed                                 Votes:                   1
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Issue Links:             Dependency
                         is dependecy of       ZF-8567    methods for setting messageId and cle...              Resolved
Fix Version Priority: Should Have

Description
The message ID created by createMessageId via setMessageId() is not valid according to RFC 2822 (section 3.6.4)
as I see it. It is missing a start '<' and end '>', causing spamassassin to score 2.6 on this alone. Fix should be trivial.




Comments
Comment by Satoru Yoshida [ 20/Dec/09 08:12 PM ]
Thank You for report, Henrik.


I will fix as soon as I will return back from Holiday.
Comment by Satoru Yoshida [ 19/Jan/10 12:50 AM ]
Sorry for my slow. Now I commit on trunk 20413. (Not yet 1.10 branch)
Comment by Satoru Yoshida [ 31/Jan/10 12:07 AM ]
merged into 1.10 branch at SVN 20783.
[ZF-8567] methods for setting messageId and clearing several headers
Created: 17/Dec/09 Updated: 30/Jan/10 Resolved: 30/Jan/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      None
Fix Version/s:          1.10.1

Type:                   Unit Tests: Improvement             Priority:              Trivial
Reporter:               Satoru Yoshida                      Assignee:              Satoru Yoshida
Resolution:             Fixed                               Votes:                 0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Dependency
                        depends on       ZF-8577     Message-ID is set not valid according...       Resolved
Fix Version Priority: Should Have

Description
I should implement tests for setting messageId and tests for clearing headers.




Comments
Comment by Satoru Yoshida [ 30/Jan/10 11:45 PM ]
Solved at SVN r20781
[ZF-8528] Patch to add SMTP pipelining support and suppression of
RCPT exceptions to Zend_Mail_Protocol_Smtp Created: 11/Dec/09 Updated: 25/Nov/10
Status:                Open
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     1.11.0
Fix Version/s:         None

Type:                  Patch                               Priority:               Minor
Reporter:              Marc Hodgins                        Assignee:               Marc Hodgins
Resolution:            Unresolved                          Votes:                  1
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified

File Attachments:          Zend_Mail_Protocol_Smtp.patch
Issue Links:           Dependency
                       depends on      ZF-8511      Zend_Mail_Protocol_Abstract - truncat...              Resolved
                       depends on      ZF-10741     Zend_Mail_Protocol_Smtp needs unit tests              Resolved

Description

Patch overview
The attached patch adds two capabilities to Zend_Mail_Protocol_Smtp:

(1) Option to enable SMTP pipelining (rfc 2920 ). This greatly speeds up SMTP delivery on high-latency
connections or when delivering many emails or recipients as there are less round-trips waiting for server responses.
(To enable, use constructor $config option pipelining=true).

$transport = new Zend_Mail_Protocol_Smtp('smtp.domain.com',
array('pipelining' => true));

(2) Option to suppress exceptions on RCPT commands. Useful if you want a message to proceed to send even if
one or more recipients are rejected by the server when the RCPT command is issued (use constructor $config option
throwRcptExceptions=false). Retrieve RCPT exceptions via getRcptExceptions() – returns an array where the keys
are the failed recipient address and the values are the stored exceptions – use $exception->getMessage() to read
each SMTP response.

$config = array('throwRcptExceptions' => false);
$transport = new Zend_Mail_Transport_Smtp('smtphost', $config));

$mail = new Zend_Mail;
$mail->setfrom('foo@bar');
$mail->setSubject('foo');
$mail->setBodyText('foo');
$mail->addTo('invalid@domain.com', 'foo'); /* would normally throw exception
*/
$mail->addTo('valid@domain.com', 'foo');
$transport->send($mail);
// iterate through rcpt exceptions
foreach ($transport->getConnection()->getRcptExceptions() as $key =>
$exception) {
    echo sprintf('Failed to send to %s - server responded "%s"', $key,
$exception->getMessage());
}

// get list of failed recipients
$exceptions       = $transport->getConnection()->getRcptExceptions();
$failedRecipients = array_keys($exceptions);

// get count of failed and successful recipients
$numFailed     = count($exceptions);
$numSuccessful = count($mail->getRecipients()) - $numFailed;


Internals
SMTP pipelining allows batches of commands (as implemented here, MAIL FROM, RCPT TO, and RSET) to be sent
without waiting for server response. This has been implemented in Zend_Mail_Protocol_Smtp by having the
_expect() function queue expected server responses until a non-pipelining command (i.e. DATA) is issued, at which
point all queued server responses are processed in sequence, evaluated against the expected responses.

 Came up with a way to mock the socket connection for unit testing; now awaiting commit of and will then add unit
tests to this patch

The patch also adds internals to facilitate future improvements related to SMTP extensions. EHLO response (the list
of server-supported SMTP extensions) is now parsed and can be queried with $this->_supports(). So, future
enhancements could include parsing of ENHANCEDSTATUSCODES (rfc 2034 ), SIZE (rfc 1870 ), etc.




Comments
Comment by Marc Hodgins [ 11/Dec/09 08:39 PM ]
Recommend applying () before this patch (ZF-8528) as resolves an issue with Zend_Mail not clearing the receive
buffer when throwing an exception. ZF-8528 needs this ability as it internally uses a try/catch block to continue
processing after an RCPT error when throwRcptExceptions config option is set to false.
Comment by Marc Hodgins [ 27/May/10 11:22 AM ]
Satoru, could you please provide comment? This patch was for ZF 1.9.6 and it would be nice to get this applied
before we're too far along if you think it is acceptable. Or, I'm happy to make changes if you feel they are needed.
Would like to get this into ZF so I can stop patching my local version with every release. Thanks.
Comment by Satoru Yoshida [ 12/Jun/10 06:23 AM ]
Sorry, I have been inactive since last April.
Comment by Marc Hodgins [ 24/Nov/10 09:53 AM ]
Linking as depending on . Will refactor this patch and add unit tests once the unit tests on are committed
[ZF-8527] Augment Zend_Mail recipient functions to take optional arrays
Created: 11/Dec/09 Updated: 14/Dec/09 Resolved: 11/Dec/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.10.0
Fix Version/s:          1.10.0

Type:                   Improvement                         Priority:                Minor
Reporter:               Eli White                           Assignee:                Eli White
Resolution:             Fixed                               Votes:                   0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Related
                        is related to     ZF-2219        addBcc() lacks 'name' parameter                  Resolved

Description
The Zend_Mail recipient functions: addTo(), addBcc(), addCc() - each only take a single email address. Augmenting
them to accept an array optionally, and automatically handle the difference between being given a single entry, or an
array, will make the functions much more flexible and match how many programmers will want to use them.




Comments
Comment by Eli White [ 11/Dec/09 02:28 PM ]
Fix committed, arrays now can be optionally passed in.
Comment by Satoru Yoshida [ 12/Dec/09 05:17 AM ]
Hello, Eli
Sadly, I do not know the process, is this based on a conclusion argued in #zftalk.dev or Mailing List?
Comment by Eli White [ 14/Dec/09 08:22 AM ]
This was based around me complaining to Matthew about lots of things, grin, including this specific point, when I was
writing some code that needed to add multiple emails, that I already had stored in an array.

And most systems would have allowed for some 'bulk add' type functionality, and ZF didn't.

Matthew's response was telling me the typical OSS response of: "So code it"

And so I did.
Comment by Matthew Weier O'Phinney [ 14/Dec/09 08:33 AM ]
Satoru – I've actually heard the request a couple of times, and since Eli was willing to code it, it made sense. He ran
the design ideas by me first, so I was aware of them.
Comment by Satoru Yoshida [ 14/Dec/09 01:56 PM ]
Thank You for quick responce, Eli and Matthew.


I feel relieved.
Because I can understand it as a result of requests and agreement by plural people.
Thank you for function improvement and addition of unittest
[ZF-8511] Zend_Mail_Protocol_Abstract - truncates server response
when SMTP server responds with umultiple line error message Created:
09/Dec/09 Updated: 24/Nov/10 Resolved: 14/Dec/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.9.6
Fix Version/s:          1.9.7

Type:                   Bug                                 Priority:               Minor
Reporter:               Marc Hodgins                        Assignee:               Satoru Yoshida
Resolution:             Fixed                               Votes:                  1
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:          Zend_Mail_Protocol_Abstract.patch
Issue Links:            Dependency
                        is dependecy of       ZF-8528     Patch to add SMTP pipelining support ...              Open
Fix Version Priority: Must Have

Description

Bug Description
SMTP servers may respond to commands with multi-line responses. A response is not complete until a response
message NOT prefixed by '-' is found. However, Zend_Mail_Protocol_Abstract throws an exception before reading
the entire response, leading to a truncated error message being included in the exception and the object being left in
an unusable state (when it could/should be left usable).


Example multi-line SMTP response to an SMTP RCPT
command
550-5.1.1 The email account that you tried to reach does not exist. Please
try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://mail.google.com/support/bin/answer.py?answer=6596
xxxxxxxxxx.xx

The _expect() method of Zend_Mail_Protocol_Abstract throws an exception upon encountering the first "550" line
rather than reading the entire multi-line response before throwing the exception. This causes two problems:

(1) The exception thrown does not contain the full response from the SMTP server, making troubleshooting and
logging difficult, and

(2) If the exception is caught, the protocol adapter remains in an unusable state because there are (in this case) three
response lines trapped in the receive buffer. Subsequent attempts to issue commands (an SMTP RSET command,
for example) will fail because the next call to _expect() will receive the "550-5.1.1 double-checking the recipient..."
line from the buffer which does not make sense.


Code to reproduce
$transport = new Zend_Mail_Transport_Smtp('ASPMX2.GOOGLEMAIL.com');
$mail       = new Zend_Mail;
$mail->setBodyText('foo')
      ->setFrom('foo@bar.com', 'foo')
      ->setSubject('foo')
      ->addTo('nobody@invalid-domain');
try {
    $transport->send($mail);
} catch (Zend_Mail_Protocol_Exception $e) {
    echo $e->getMessage();
}


Expected Output
550-5.1.1     The email account that you tried to reach does not exist. Please
try
550-5.1.1     double-checking the recipient's email address for typos or
550-5.1.1     unnecessary spaces. Learn more at
550 5.1.1     http://mail.google.com/support/bin/answer.py?answer=6596


Actual output
550-5.1.1 The email account that you tried to reach does not exist. Please
try


Solution
See attached patch




Comments
Comment by Marc Hodgins [ 10/Dec/09 12:00 AM ]
Patch for Zend/Mail/Protocol/Abstract.php
Comment by Satoru Yoshida [ 14/Dec/09 02:14 AM ]
Thank You for report , Marc.
I solved this at SVN trunk r19629
Comment by Satoru Yoshida [ 24/Dec/09 02:37 AM ]
Change to next mini. SVN r19916 in 1.9 branch.
[ZF-8503] _formatAddress creates invalid format if Email and Name are
both emailaddresses (different ones) Created: 09/Dec/09 Updated: 12/Dec/09 Resolved: 12/Dec/09
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.9.6
Fix Version/s:           1.10.0

Type:                    Bug                                     Priority:          Major
Reporter:                Jonas Wüste                             Assignee:          Satoru Yoshida
Resolution:              Fixed                                   Votes:             0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
If both arguments of _formatAddress are emailadresses, this function creates an invalid Header.
Called like this: _formatAddress('jonas@email.de','jonas@email2.de') creates following return value:
'jonas@email2.de <jonas@email.de>'
Using this value as a Headervalue like "From", the From-Field is displayed incorrect. In Outlook the header looks like
'From: "jonas@" <email2.de jonas@email.de>'

This is because the name should be quoted.

The easiest way to fix it is to change the function like this:

Mail.php
protected function _formatAddress($email, $name)
    {
        if ($name === '' || $name === null || $name === $email) {
            return $email;
        } else {
            $encodedName = $this->_encodeHeader($name);
            if ($encodedName === $name && (strpos($name, ',') !== false ||
strpos($name, '@') !== false)) {
                 $format = '"%s" <%s>';
            } else {
                 $format = '%s <%s>';
            }
            return sprintf($format, $encodedName, $email);
        }
    }

Greetings,
Jonas




Comments
Comment by Satoru Yoshida [ 12/Dec/09 08:51 PM ]
I think it may be Outlook problem.
but I added some logic that you can handle name including at mark

SVN trunk r19608
[ZF-8493] Zend_Mail_Transport_Sendmail creates warning if it doesnt
exist instead of throwing an exception Created: 08/Dec/09 Updated: 24/Dec/09 Resolved:
17/Dec/09
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.9.6
Fix Version/s:           1.9.7

Type:                    Bug                                   Priority:              Minor
Reporter:                R Slootjes                            Assignee:              Satoru Yoshida
Resolution:              Fixed                                 Votes:                 0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
The _sendMail() function doesnt check if mail() is actually available. When I run it on my local XAMPP installation I
don't have the mail-function available and it will return an error about that. If the mail would have the error surpressed
I will get an exception. So, please place @'s before the mail() functions so I can catch the exception without getting
extra errors/warnings. Simple fix I guess




Comments
Comment by Satoru Yoshida [ 14/Dec/09 02:35 AM ]
Hi, R Slootjes.

In substitution for @ mark, could it also match Your purpose like as following code ?

if (function_exists('mail') === false) {
    require_once 'Zend/Mail/Transport/Exception.php';
    throw new Zend_Mail_Transport_Exception('Unable to use mail');
}
Comment by R Slootjes [ 14/Dec/09 04:33 AM ]
That won't be sufficient since this:

var_dump(function_exists('mail'));

displays

bool(true).

The function exists but it's just not configured to work (i guess).
Comment by Satoru Yoshida [ 14/Dec/09 06:05 AM ]
Thank You for responce, R Slootjes.
Then I will be happy if you would try the following code.

//Add property
protected $_errstr;

public function _sendMail()
{
    //Add next line
    set_error_handler(array($this, '_handleSomeErrors'));
    if ($this->parameters === null) {
        $result = mail(
             $this->recipients,
             $this->_mail->getSubject(),
             $this->body,
             $this->header);
    } else {
        $result = mail(
             $this->recipients,
             $this->_mail->getSubject(),
             $this->body,
             $this->header,
             $this->parameters);
    }
    //Add next line
    restore_error_handler();

    //Change next line
    if ($this->_errstr !== null || !$result) {
        require_once 'Zend/Mail/Transport/Exception.php';
        //Change next argument
        throw new Zend_Mail_Transport_Exception('Unable to send mail:' .
$this->_errstr);
    }
}

//Add function
protected function _handleSomeErrors($errno, $errstr, $errfile = null,
$errline = null, array $errcontext = null)
{
    $this->_errstr = $errstr;
    return true;
}
Comment by R Slootjes [ 16/Dec/09 03:28 AM ]

I will try to test this today, i just got some tight deadlines
Comment by R Slootjes [ 17/Dec/09 01:21 AM ]
This seems to be working like it should:

try
{
            $objMail = new Zend_Mail();
            $objMail->setBodyHtml('<h1>Test</h1>');
            $objMail->setFrom('robert@sender.com', 'Robert');
            $objMail->addTo('robert@receiver.com', 'Robert');
            $objMail->setSubject('Testmail');
            $objMail->send();
}
catch(Exception $objException)
{
           echo 'exception: ' . $objException->getMessage();
}

returns:

exception: Unable to send mail:mail() [<a
href='function.mail'>function.mail</a>]: Failed to connect to mailserver at
&quot;localhost&quot; port 25, verify your &quot;SMTP&quot; and
&quot;smtp_port&quot; setting in php.ini or use ini_set()
Comment by Satoru Yoshida [ 17/Dec/09 07:20 AM ]

Thank You for cooperation, R Slootjes     I reflected it at SVN trunk r19712.
Comment by Satoru Yoshida [ 24/Dec/09 02:25 AM ]
change to next mini. SVN r19915 in 1.9 branch
[ZF-8436] Add Zend_App_Resource_Mail Created: 01/Dec/09                          Updated: 19/Jan/10 Resolved:
02/Jan/10
Status:              Resolved
Project:             Zend Framework
Component/s:         Zend_Application_Resource, Zend_Mail
Affects Version/s:   1.10.0
Fix Version/s:       1.10.0

Type:                New Feature                      Priority:              Major
Reporter:            Dolf Schimmel (Freeaqingme)      Assignee:              Dolf Schimmel (Freeaqingme)
Resolution:          Fixed                            Votes:                 1
Remaining Estimate: Not Specified
Time Spent:          Not Specified
Original Estimate:   Not Specified

File Attachments:       Mail.php      ZF-8436.patch
Issue Links:         Related
                     is related to   ZF-4955   Have zend_mail support instantiation ...             Resolved

Description
<?php
/**
 * Configuration options (INI):

 * application.resources.mail
 * application.resources.mail.protocol = smtp
 * application.resources.mail.host = mail.domain.com
 * application.resources.mail.options.port = 2626
 * application.resources.mail.options.auth = login
 * application.resources.mail.options.username = info+domain.com
 * application.resources.mail.options.password = *secret8
 * application.resources.mail.registry.sender.from = info@domain.com
 * application.resources.mail.registry.sender.name - no-reply
 *
 * NOTE : The resource loader will store in Zend_Registry, the array
 *
 * array(
 *    'sender' => 'info@domain.com'
 *    'name'   => 'no-reply'
 * );
 *
 * Custom registry key can be specified through the registryKey option
 *
 */

/**
  * @author yanick[-dot-]rochon[-at-]gmail[-dot-]com
  */
class Phoo_Application_Resource_Mail
     extends Zend_Application_Resource_ResourceAbstract
{
            const DEFAULT_REGISTRY_KEY = 'Zend_Mail_Options';


            public function init()
      {
            $options = $this->getOptions();

            $transportType = ucfirst(strtolower($options['protocol']));
            $transportHost = $options['host'];
                    $transportOptions = $options['options'];

            $transportClass = "Zend_Mail_Transport_{$transportType}";

                $transport = new $transportClass($transportHost,
$transportOptions);

                        Zend_Mail::setDefaultTransport($transport);

                        if (isset($options['registry'])) {
                                if (isset($options['registryKey'])) {
                                         $registryKey = $options['registryKey'];
                                } else {
                                         $registryKey = self::DEFAULT_REGISTRY_KEY;
                                }

                                    Zend_Registry::set($registryKey,
$options['registry']);
                }
    }

}


Comments
Comment by David Caunt [ 08/Dec/09 03:51 AM ]
A basic mail resource which could be extended to support more otpions
Comment by Dolf Schimmel (Freeaqingme) [ 15/Dec/09 03:34 PM ]
Attached proposed patch. No unittests available yet.
Comment by Dolf Schimmel (Freeaqingme) [ 02/Jan/10 12:49 PM ]
Done in trunk, to be released in 1.10
[ZF-8278] Out of memory on large sends Created: 10/Nov/09                                   Updated: 17/Nov/09 Resolved:
17/Nov/09
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       None
Fix Version/s:           1.10.0

Type:                    Improvement                           Priority:                Minor
Reporter:                Luke Richards                         Assignee:                Satoru Yoshida
Resolution:              Fixed                                 Votes:                   2
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Fix Version Priority: Should Have

Description
When sending large amounts of email using the Zend_Mail_Transport_Protocol classes it causes an out of memory
problem. This is because each time the protected send method is called it attaches the request to the end of the log.
In cases when a lot of emails are being sent this grows eventually causing the memory limit error.

I'm not sure this is the correct solution but I fixed it by resetting the log every time the send method is called:

class Yourlibrary_Mail_Transport_Smtp extends Zend_Mail_Transport_Smtp
{
    /**
      * Send a mail using this transport
      *
      * @param Zend_Mail $mail
      * @access public
      * @return void
      * @throws Zend_Mail_Transport_Exception if mail is empty
      */
    public function send(Zend_Mail $mail)
    {
         $connection = $this->getConnection();
         if ($connection instanceof Zend_Mail_Protocol_Smtp) {
             $connection->resetLog();
         }
         return parent::send($mail);
    }
}


Comments
Comment by Fabio Napoleoni [ 10/Nov/09 04:28 PM ]
In my case the patch work, I send a small list of about 800 members and without this class my script crashes unless I
raise memory limit up to 256M or even 512M.

But with this class the problem is gone.
Comment by Satoru Yoshida [ 14/Nov/09 05:32 AM ]
I think notation would be helpful.
The notation in document should notice in case user send many mails.

So, I change this issue to Docs: Improvement.
Comment by Satoru Yoshida [ 16/Nov/09 08:13 PM ]
I added limitation of log counts at SVN r19008 (trunk).


I will be happy if you would try new code
This improvement would be released at 1.10.0 or later.
[ZF-8273] setReturnPath overwrites setFrom in
Zend_Mail_Protocol_Smtp Created: 10/Nov/09 Updated: 06/Nov/10                         Resolved: 06/Nov/10
Status:                Closed
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.1, 1.7.2, 1.7.3, 1.7.4, 1.7.5, 1.7.6, 1.7.7, 1.7.8, 1.8.0, 1.8.1, 1.8.2,
                       1.8.3, 1.8.4, 1.9.0, 1.9.1, 1.9.2, 1.9.3, 1.9.4, 1.9.5
Fix Version/s:         1.9.6

Type:                  Bug                                    Priority:                 Blocker
Reporter:              Marcin Gil                             Assignee:                 Marc Hodgins
Resolution:            Fixed                                  Votes:                    1
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified

Issue Links:           Dependency
                       depends on         ZF-7008       Method setReturnPath() not working                      Resolved

Description
$mail = new Zend_Mail();
$mail->setFrom('sender@email.com');
$mail->setReturnPath('returns@email.com');
$mail->send( .. Zend_Mail_Transport_Smtp .. );

E-mail is being sent on returns@email.com instead of sender@email.com;

Zend_Mail_Transport_Smtp, line 203:
$this->_connection->mail($this->_mail->getReturnPath());

Please fix.




Comments
Comment by Satoru Yoshida [ 14/Nov/09 04:59 AM ]
Hi, Marcin.

Do you mean you find mail returns back when some error is happened?
Or, you find [from] address is changed on your mailer?
Comment by Marcin Gil [ 14/Nov/09 05:06 AM ]
Hi Satoru,

I mean that e-mail is sent from "returns@email.com" instead of "sender@email.com".
I understand that e-mail should be sent from "sender@email.com" with Return-Path header set to
"returns@email.com" - in case of error.
Do I understand incorrectly?

Cheers,
Marcin
Comment by Satoru Yoshida [ 15/Nov/09 05:37 AM ]
I change code in SVN r18988 (trunk), 18989 (1.9 branch) .

You are correct, Marcin.
For your purpose, getReturnPath() should be replaced with getFrom().


And I have a sadly information I must notice you
As it is pointed out in , setReturnPath can not work fine now.

The function is under consideration how to fix.
Comment by Janis Lünne [ 27/Jul/10 05:46 AM ]
Hi Satoru, hi Marcin,

unfortunately this is broken now.
The Return-Path has to be used as MAIL FROM: in the SMTP transport.
So please undo your replacement of getReturnPath() with getFrom(), because it was working correctly before.

Thanks,
Janis
Comment by Dolf Schimmel (Freeaqingme) [ 27/Jul/10 05:52 AM ]
Please present some code to reproduce, and describe the problem with that code. Thanks.
Comment by Janis Lünne [ 28/Jul/10 07:51 AM ]
Zend_Mail_Transport_Smtp, line 203:
was (correct):
$this->_connection->mail($this->_mail->getReturnPath());
is now (incorrect):
$this->_connection->mail($this->_mail->getFrom());

This results in always using the "Body-From" (From:-Header), as "Envelope-From" ("MAIL FROM:" SMTP command)
and removes the possibility to use different Envelope-From and Body-From Addresses.

See RFC 2821 and http://en.wikipedia.org/wiki/Bounce_address     for reference.
Comment by Dolf Schimmel (Freeaqingme) [ 28/Jul/10 07:54 AM ]
Ouch. Will fix tonight.
Comment by Stephan Wentz [ 09/Aug/10 03:59 AM ]
bump


It's still not fixed in trunk - and it breaks our mail code
Comment by Marc Hodgins [ 06/Nov/10 02:46 AM ]
was opened because this was not actually a bug and the "solution" broke Zend_Mail to not be compliant with the
RFC with the SMTP transport.

Closing this issue to avoid confusion – see for the fix.
[ZF-8163] Zend_Mail_Protocol_Imap connect method throws possibly
misleading exception message on socket open failure Created: 27/Oct/09 Updated:
28/Oct/09 Resolved: 28/Oct/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.9.5
Fix Version/s:          1.9.6

Type:                   Bug                                  Priority:               Trivial
Reporter:               Filipus Klutiero                     Assignee:               Satoru Yoshida
Resolution:             Fixed                                Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Fix Version Priority: Should Have

Description
Zend_Mail_Protocol_Imap->connect() throws an exception this way is fsockopen fails:

$this->_socket = @fsockopen($host, $port, $errno, $errstr,
self::TIMEOUT_CONNECTION);
        if (!$this->_socket) {
            /**
             * @see Zend_Mail_Protocol_Exception
             */
            require_once 'Zend/Mail/Protocol/Exception.php';
            throw new Zend_Mail_Protocol_Exception('cannot connect to host :
' . $errno . ' : ' . $errstr);
        }

So for example, in case of a timeout, the exception has the following message:

cannot connect to host : 110 : Connection timed out

When I got this trying to connect to an IMAP server, I figured the Zend-based software was trying to connect via
POP3, which uses port 110, and that for some reason the error missed the hostname but only showed the port. I
realized in the end that 110 wasn't a port but an errno. It is not entirely wrong though to expect a hostname after "host
:". I would suggest this form instead:

'Cannot connect to host. connect(): error ' . $errno . ' (' . $errstr . ')'


Comments
Comment by Satoru Yoshida [ 28/Oct/09 09:18 PM ]
Thank you for report and sorry for patience, Filipus.

Solved in svn r18730 (trunk), r18731 (1.9branch).
Comment by Filipus Klutiero [ 28/Oct/09 11:25 PM ]
Come on... I've rarely seen issues treated so fast.

Thank you
[ZF-8162] Several TYPOs in Zend_Mail_Protocol_Imap and
Zend_Mail_Protocol_Pop3 Created: 27/Oct/09 Updated: 28/Oct/09 Resolved: 28/Oct/09
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     1.9.5
Fix Version/s:         1.9.6

Type:                  Bug                                Priority:              Trivial
Reporter:              Filipus Klutiero                   Assignee:              Satoru Yoshida
Resolution:            Fixed                              Votes:                 0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified

Fix Version Priority: Nice to Have

Description
Zend_Mail_Protocol_Imap->connect has synopsis "Open connection to POP3 server". There's a bit too much copy-
pasting here:

/**
        * Open connection to POP3 server
        *
        * @param string       $host hostname of IP address of POP3 server
        * @param int|null     $port of IMAP server, default is 143 (993 for
ssl)
         * @param string|bool $ssl    use 'SSL', 'TLS' or false
         * @return string welcome message
         * @throws Zend_Mail_Protocol_Exception
         */
       public function connect($host, $port = null, $ssl = false)
       {

The $host parameter's description also needs to be fixed. BTW, this should read "hostname or IP address", not
"hostname of IP address".




Comments
Comment by Satoru Yoshida [ 28/Oct/09 06:17 AM ]
Thank you for report, Filipus.
I fixed several TYPOs in PHPDoc at r18725 in trunk.

1) from "hostname of IP address" to "hostname or IP address" .

PHPDoc of connect() and __construct() in Zend_Mail_Protocol_Imap .
And same in Zend_Mail_Protocol_Pop3 .

2) from "POP3" to "IMAP" .
2 TYPOs in connect() in Zend_Mail_Protocol_Imap .
[ZF-7978] method Zend_Mail_Protocol_Imap::_decodeLine() incorrectly
parse some tokens Created: 29/Sep/09 Updated: 08/Oct/09 Resolved: 08/Oct/09
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.9.3
Fix Version/s:           1.9.4

Type:                    Bug                                 Priority:               Major
Reporter:                Sergei Stolyarov                    Assignee:               Satoru Yoshida
Resolution:              Fixed                               Votes:                  0
Remaining Estimate: 1 hour
Time Spent:              Not Specified
Original Estimate:       1 hour

Issue Links:             Related
                         is related to   ZF-7547     Zend_Mail_Protocol_Imap::_decodeLine ...                  Resolved
Fix Version Priority: Should Have

Description
Try to parse (using Zend_Mail_Protocol_Imap::_decodeLine() ) the following line "* STATUS blurdybloop
(MESSAGES 231 UNSEEN 0)", in the result you'll miss last "0" token. It's because of incorrect parsing of tokens in
the following code fragment (file Zend/Mail/Protocol/Imap.php)

// only add if token had more than just closing braces
                if ($token) {
                    $tokens[] = $token;
                }

In input line above last token is "0" but expression "if ($token) {" treat it as numeric 0 and hence as a FALSE value.
So instead of adding string "0" code ignores it.




Comments
Comment by Satoru Yoshida [ 08/Oct/09 05:34 AM ]
Sergei, I think following code, do you think? If "(some strings 0 )" would be passed, it seems to work fine.

if (rtrim($token) != '') {
    $tokens[] = rtrim($token);
}
Comment by Sergei Stolyarov [ 08/Oct/09 09:41 AM ]
Yes, it looks fine for me.
Comment by Satoru Yoshida [ 08/Oct/09 03:24 PM ]
Thanks, solved at SVN r18498 in trunk
[ZF-7932] Zend Mail will add a "= " in the subject, if subject contains
unpritable characters Created: 23/Sep/09 Updated: 24/Sep/09 Resolved: 24/Sep/09
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.6.2
Fix Version/s:           None

Type:                    Bug                                  Priority:                Major
Reporter:                Joe Chen                             Assignee:                Dolf Schimmel (Freeaqingme)
Resolution:              Cannot Reproduce                     Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
$mail = new Zend_Mail("UTF-8");
$mail->setFrom($senderEmail, $senderName);

$mail->addTo('xxx@xxx.com');
$mail->setSubject("Inloggningsuppgifter till PriceRunners
Återförsäljargränssnitt");
$mail->setBodyHtml("<b>Inloggningsuppgifter till PriceRunners
Återförsäljargränssnitt</b>\n");

I will get the email with the subject "Inloggningsuppgifter till PriceRunners Återförsäljargr= nssnitt"

protected function _encodeHeader($value) {
      if (Zend_Mime::isPrintable($value)) {
          return $value;
      } else {
          $quotedValue = Zend_Mime::encodeQuotedPrintable($value);
          $quotedValue = str_replace(array('?', ' ', '_'), array('=3F',
'=20', '=5F'), $quotedValue);
          return '=?' . $this->_charset . '?Q?' . $quotedValue . '?=';
      }
}

The Zend_Mime::encodeQuotedPrintable($value); but havnt give the function the second parameter
or else the system will add "=\n" at position 74




Comments
Comment by Benjamin Eberlei [ 24/Sep/09 11:16 AM ]
seriously 1.6.2? please upgrade to at least 1.8.4 this issue should be fixed.
Comment by Dolf Schimmel (Freeaqingme) [ 24/Sep/09 05:33 PM ]
I tried to reproduce using trunk (somewhere near-updated) and was not able to reproduce the issue. Meaning the
subject did contain a lot of =-characters, but all according to the specs, given the fact that my client (kmail in this
case) did not display any of them. Please note that a lot of effort has been put in utf8 and zend_mail recently, and
that you should probably upgrade if you encounter this problem (or try backporting zend_mail).
[ZF-7874] Zend_Mail_Transport should not add charset parameter to
multipart Content-Type header Created: 17/Sep/09 Updated: 31/Oct/09 Resolved: 31/Oct/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.9.2
Fix Version/s:          1.9.6

Type:                   Bug                                  Priority:               Major
Reporter:               O Gray                               Assignee:               Satoru Yoshida
Resolution:             Fixed                                Votes:                  0
Remaining Estimate: 1 day
Time Spent:             Not Specified
Original Estimate:      1 day

Fix Version Priority: Should Have

Description
When generating a multipart (text and html) message, Zend_Mail includes the following in the headers:

Content-Type: multipart/alternative; charset=iso-8859-1;
 boundary="=--whatever--"

As far as I can tell, the charset parameter is not appropriate to a multipart/alternative Content-Type declaration.

from RFC 2045, p. 10:

For example, the "charset" parameter is applicable to any subtype of
"text", while the "boundary" parameter is required for any subtype of
the "multipart" media type.

At http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PK48897              I found this:

The
charset parameter isn't valid in the headers
of ANY multipart type. Neither the
multipart/related specification nor any
example in any specification suggests that
it should be allowed. It only applies to
text and to text-related formats such as
application/xml. The body of a
multipart/related document is not text so it
cannot have a charset. It is a collection
of parts which are required to consist of
valid 7-bit ASCII headers combined with data
in whatever encoding is specified in the
content-type and content-encoding headers
for the relevant part.

The inclusion of the charset parameter causes at least one webmail client (UebiMiau 2.7.10) to choke on the
message.
modifying the _getHeaders() fucntion in Zend/Mail/Transport/Abstract.php to change this:

$this->_headers['Content-Type'] = array(
                $type . '; charset=' . $this->_mail->getCharset() . ';'
                . $this->EOL
                . " " . 'boundary="' . $boundary . '"'
            );

to this

$this->_headers['Content-Type'] = array(
                $type . ';'
                . $this->EOL
                . " " . 'boundary="' . $boundary . '"'
            );
            $this->boundary = $boundary;
        }

Solved the problem with the web client

Also, if a message generated by the existing code is run through message lint at http://www.apps.ietf.org/node/11 , it
warns: "WARNING: Unexpected parameter 'charset' in header 'Content-Type'"




Comments
Comment by Oliver Baltz [ 06/Oct/09 03:40 AM ]
This fix seems to work for me:

protected function _getHeaders($boundary)
{
if (null !== $boundary) {
// Build multipart mail
$type = $this->_mail->getType();
if (!$type) {
if ($this->_mail->hasAttachments) { $type = Zend_Mime::MULTIPART_MIXED; } elseif ($this->_mail->getBodyText()
&& $this->_mail->getBodyHtml()) { $type = Zend_Mime::MULTIPART_ALTERNATIVE; } else { $type =
Zend_Mime::MULTIPART_MIXED; }
}

$addCharset = !in_array($type, array(
Zend_Mime::MULTIPART_MIXED,
Zend_Mime::MULTIPART_ALTERNATIVE,
Zend_Mime::MULTIPART_MIXED
));

$this->_headers['Content-Type'] = array(
$type . ( $addCharset ? ( '; charset=' . $this->_mail->getCharset() ) : "" ) . ';'
. $this->EOL
. " " . 'boundary="' . $boundary . '"'
);
$this->boundary = $boundary;
}

$this->_headers['MIME-Version'] = array('1.0');
return $this->_headers;
}
Comment by O Gray [ 06/Oct/09 05:08 AM ]
Mr. Baltz's proposed fix assumes that there is some Multipart type for which charset is a valid header parameter. The
reference I quoted from the IBM site is categorical that this is not so. Is there some authority to the contrary?

Zend_Mime only contemplates three multipart types: MULTIPART_ALTERNATIVE, MULTIPART_MIXED and
MULTIPART_RELATED. Zend_Mail only permits those three types (see Zend_Mail::setType). Thus, this fix would
permit a charset header parameter for the MULTIPART_RELATED type only. That type is defined in
http://tools.ietf.org/html/rfc2387 . Nothing in that definition suggests that charset is a valid header parameter for that
type.

It seems odd that Zend_Mime::MULTIPART_MIXED is mentioned twice in this part of the _getHeaders function (this
is presumably why Mr. Baltz includes Zend_Mime::MULTIPART_MIXED twice in the array his code adds):

if (!$type) {
if ($this->_mail->hasAttachments) {
$type = Zend_Mime::MULTIPART_MIXED;
} elseif ($this->_mail->getBodyText() && $this->_mail->getBodyHtml()) {
$type = Zend_Mime::MULTIPART_ALTERNATIVE;
} else {
$type = Zend_Mime::MULTIPART_MIXED;
}
}

I wonder if the code I have just quoted should have been:

if (!$type) {
if ($this->_mail->hasAttachments) {
$type = Zend_Mime::MULTIPART_MIXED;
} elseif ($this->_mail->getBodyText() && $this->_mail->getBodyHtml()) {
$type = Zend_Mime::MULTIPART_ALTERNATIVE;
} else {
$type = Zend_Mime::MULTIPART_RELATED;
}
}

In any event, if charset is not a valid parameter in the header of any multipart type (as opposed to the header of a
part), then its seems better (and simpler) just to eliminate it from the _getHeaders() function altogether.
Comment by Satoru Yoshida [ 06/Oct/09 08:40 PM ]
Thank you for the suggestions, Oliver Baltz and O Gray . I'm working now, and I'll be happy if you give me several
weeks, Thanks
Comment by Satoru Yoshida [ 31/Oct/09 06:13 AM ]
Solved in SVN r18759 of trunk, r18760 of 1.9 branch.

But 2 Zend_Mime::MULTIPART_MIXEDs seem to be correct.

I think 2nd Zend_Mime::MULTIPART_MIXED is default value if script can not set the type automatically.
[ZF-7841] Zend Mail sends to undisclosed-recipients when recipients
name is empty or recipients name is set to recipients email Created: 14/Sep/09
Updated: 15/Sep/09 Resolved: 15/Sep/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.9.2
Fix Version/s:          None

Type:                   Bug                               Priority:              Major
Reporter:               Rune Viem                         Assignee:              Satoru Yoshida
Resolution:             Won't Fix                         Votes:                 0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
Mail sent with Zend_Mail shows up as sent to undisclosed-recipients, if Zend_Mail method addTo($email, $name) is
fed with empty $name or $name equals $email.

I have changed the function _formatAddress in Zend_Mail class to resolve this:

protected function _formatAddress($email, $name)
    {
        if ($name && $name!='') {
                 $encodedName = $this->_encodeHeader($name);
        } else {
                 $name = $email;
                 $encodedName = $this->_encodeHeader($email);
        }
        if ($encodedName === $name && strpos($name, ',') !== false) {
              $format = '"%s" <%s>';
        } else {
                 $format = '%s <%s>';
        }
        return sprintf($format, $encodedName, $email);


      }


Comments
Comment by Satoru Yoshida [ 14/Sep/09 06:36 AM ]
I think your mail client may not follow RFC sadly.
Comment by Satoru Yoshida [ 15/Sep/09 06:50 PM ]
The <%s> part is not required when the name is not specified or the name is equal to the address.
[ZF-7799] Zend_Mail Blank line above all emails sent Created: 08/Sep/09                                  Updated:
18/Sep/09 Resolved: 18/Sep/09
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     1.9.2
Fix Version/s:         1.9.3

Type:                  Bug                                 Priority:                  Trivial
Reporter:              Dave Miller                         Assignee:                  Benjamin Eberlei
Resolution:            Fixed                               Votes:                     0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified

File Attachments:          patch_ZF7799.diff

Description
When Zend_Mail sends an email, there is one too many blank lines between the headers and the body. Most email
clients seem to ignore this, but Gmail shows the blank line.

As far as I can tell, Zend_Mail_Transport_Abstract::_prepareHeaders() always puts a new line after the headers, then
Zend_Mail_Transport_Sendmail::_sendMail() passes this straight to the mail() function. Putting trim() in either
function solves it for me, but I have not tested other transports.




Comments
Comment by Benjamin Eberlei [ 18/Sep/09 05:01 AM ]
Confirmed on outlook 2007, it also shows the additional blank line.
Comment by Benjamin Eberlei [ 18/Sep/09 05:43 AM ]
I have checked this issue and it appears to be a Sendmail Transport specific issue.


I will add a patch and unittest and apply that tonight when i have my SVN account credentials with me
Comment by Benjamin Eberlei [ 18/Sep/09 11:24 AM ]
Fixed in trunk and merged back into 1.9 release branch
[ZF-7728] File "Zend/Validate/Hostname/Com.php" does not exist or
class "Zend_Validate_Hostname_Com" was not found in the file Created:
31/Aug/09 Updated: 18/Sep/09 Resolved: 18/Sep/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.9.2
Fix Version/s:          None

Type:                   Bug                                  Priority:             Major
Reporter:               Jean-Francois Monfort                Assignee:             Nico Edtinger
Resolution:             Not an Issue                         Votes:                0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
When I create a new instance of Zend_Mail_Transport_Smtp() with the first parameter a .com domain I got these
error ;

File "Zend/Validate/Hostname/Com.php" does not exist or class "Zend_Validate_Hostname_Com" was not found in
the file

here is my code

$t = new \Zend_Mail_Transport_Smtp('smtp.domain.com');

$mail = new \Zend_Mail();
...
$mail->send($t);




Comments
Comment by Thomas Weidner [ 31/Aug/09 05:56 AM ]
When you are getting this error than you don't use ZF 1.9.x.
Check your installation. This file is provided and available since ZF 1.8.x
Comment by Jean-Francois Monfort [ 31/Aug/09 06:42 AM ]
I am using the 1.9.2 version.
The file Zend/Validate/Hostname/Com.php is available but there are no Class, only a return array();
Comment by Thomas Weidner [ 31/Aug/09 09:12 AM ]
Of course is there only an array and no class.

Looking into Zend_Validate_Hostname around line 417 you will see that the file is included by calling
include 'Zend/Validate/Hostname/Com.php'. This way the regex from this file is assigned to be searched through. It's
no class file but a ressource file.

As the file can not be found in your system it seems that you have eighter a configuration problem or no access to the
related directory or you've mixed several versions of Zend Framework.
Comment by Benjamin Eberlei [ 18/Sep/09 04:57 AM ]
I close this issue since no further feedback is given and after a review i think the code must work as thomas
described it.
[ZF-7702] E-Mail is sent to Reply-To if given Created: 27/Aug/09                               Updated: 04/Jan/10 Resolved:
04/Jan/10
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.9.0
Fix Version/s:           1.10.0

Type:                    Bug                                     Priority:             Major
Reporter:                Marius Mühlberger                       Assignee:             Dolf Schimmel (Freeaqingme)
Resolution:              Fixed                                   Votes:                0
Remaining Estimate: 3 days
Time Spent:              Not Specified
Original Estimate:       3 days

File Attachments:           replyTo.patch
Fix Version Priority: Should Have

Description
Adding a reply-to address (via setReplyTo()) and sending the mail results in sending the mail to the given address
additionaly to TO/CC/BCC.




Comments
Comment by Jachim Coudenys [ 08/Sep/09 05:39 AM ]
The setReplyTo() function uses _addRecipientAndHeader, but should work like setFrom(), where only the header is
set.
Comment by Jachim Coudenys [ 08/Sep/09 06:40 AM ]
This is the first patch I make, so I hope it's a good one.

The patch fixes the the Reply-To header functions. It's acting like the ReturnPath functions.
Comment by Benjamin Eberlei [ 18/Sep/09 06:35 AM ]
Are you doing this on windows and using the Sendmail Transport.
Comment by Jachim Coudenys [ 18/Sep/09 07:11 AM ]
I am, but this has nothing to do with the fact that the Reply-To address is added to the receivers list, I think.
Comment by Oliver Baltz [ 05/Oct/09 12:46 PM ]
I'm experiencing same bug with SMTP under Linux! The Reply-To address must not be added to the list of recipients,
but just to the headers.
Comment by Dolf Schimmel (Freeaqingme) [ 15/Oct/09 07:17 PM ]
Issue fixed. Thank you for reporting.
Comment by Satoru Yoshida [ 15/Oct/09 10:35 PM ]
Thank you, Dolf.
And I add some fix at trunk SVN r18566:
1) from tab code to 4 spaces.
2) from $name = $this->_filterEmail($name); to $name = $this->_filterName($name);
Comment by Jachim Coudenys [ 16/Oct/09 12:10 AM ]
Was the patch useful?
Just to know if I should create other patches in the future...
Comment by Thomas Weidner [ 16/Oct/09 12:40 AM ]
Patches are always usefull.

Even if te committer does not use it, he will always look at your sugestion and become an much better idea of what
your problem and solution is.

It also gives you a better understanding of the framework.

And when you also add unittests to your patch, then the committer can use it completly without changes.
Comment by Dolf Schimmel (Freeaqingme) [ 16/Oct/09 10:04 AM ]
Yes, the patch certainly was useful as I hardly know anything about Zend_Mail (I did use it once though!). For some
reason however your patch was pretty mangled up by which it was hard to see what actually did change, that is why I
only used it as a reference. So please; do attach a patch too in future where possible, it is always appreciated!
Comment by Michael Sheakoski [ 27/Dec/09 11:02 PM ]
This issue still exists as of v1.9.6. Seems like the patch never made it in.
Comment by Satoru Yoshida [ 04/Jan/10 08:27 PM ]
Hi, Michael,
It seems that possibly you might misunderstand about the Next Minor Release, for me.

the Next Minor Release means not 1.9.x but 1.10.0 .
I hope this comment could help you.
[ZF-7578] Zend_Mail bug: Html mail does not work in apple mail Created:
12/Aug/09 Updated: 19/Jan/10 Resolved: 19/Jan/10
Status:                        Closed
Project:                       Zend Framework
Component/s:                   Zend_Mail
Affects Version/s:             1.8.1
Fix Version/s:                 None

Type:                          Bug                           Priority:                Major
Reporter:                      xinghao                       Assignee:                Satoru Yoshida
Resolution:                    Incomplete                    Votes:                   0
Remaining Estimate: Not Specified
Time Spent:                    Not Specified
Original Estimate:             Not Specified


Description
I try to send a html email like that:

--------------------------------------------------------
$mailer = new Zend_Mail('utf-8');
$mailer->addTo(...);
$mailer->setSubject(...);
$mailer->setBodyHtml('.....', 'utf8');
$mailer->setFrom(...);
$mailer->send();
----------------------------------------------------------

When i receive this mail in gmail everything is good i can see html page.
But when i receive this mail using apple mail i see the html content becoming an attachment.




Comments
Comment by Marc Bennewitz (GIATA mbH) [ 02/Oct/09 03:11 AM ]
Hi

Currently I had a similar problem with Windows Live Mail 2008/9 but after testing many different configuration I could
fix it:
-> mail.add_x_header = Off in php.ini

I don't no if this was the bug described here "http://bugs.php.net/bug.php?id=48620" or if this is an bug/feature of the
Mail Client.
But if it is activated the Client breaks parsing Mail after this Header and display the source starting on this position.
Comment by Satoru Yoshida [ 04/Dec/09 11:43 PM ]
Hi, xinghao.

Do you use Chinese language with Zend_Mail? If so , I will be happy if you try followings.

1)
set encoding hz-gb-2312 (GB2312) or Big5 instead of UTF-8 to Zend_Mail().
2)
setBodyText(mb_convert_encoding($txt, 'YOUR ENCODING', mb_detect_encoding($txt)) , $charset , $encoding );
Comment by Satoru Yoshida [ 19/Jan/10 05:23 AM ]
I will close this because no responce for one month or more.
It seems to be client-dependent problem for me.
[ZF-7335] Multiple files in library/ or in tests/ don't have the
svn:keywords=id Created: 21/Jul/09 Updated: 18/Mar/10 Resolved: 18/Aug/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Acl, Zend_Amf, Zend_Application, Zend_Auth, Zend_Auth_Adapter_Ldap,
                        Zend_Auth_Adapter_OpenId, Zend_Cache, Zend_Captcha, Zend_CodeGenerator,
                        Zend_Config, Zend_Config_Writer, Zend_Console_Getopt, Zend_Controller, Zend_Crypt,
                        Zend_Db, Zend_Db_Adapter_Db2, Zend_Db_Adapter_Mysqli, Zend_Db_Adapter_Oracle,
                        Zend_Db_Profiler, Zend_Db_Select, Zend_Db_Table, Zend_Debug, Zend_Dojo,
                        Zend_Dom_Query, Zend_Feed, Zend_Feed_Reader, Zend_File_Transfer, Zend_Filter,
                        Zend_Filter_Inflector, Zend_Filter_Input, Zend_Form, Zend_Gdata, Zend_Http_Client,
                        Zend_Http_Cookie, Zend_Http_CookieJar, Zend_Http_Response, Zend_Http_Server,
                        Zend_InfoCard, Zend_Json, Zend_Json_Server, Zend_Layout, Zend_Ldap, Zend_Loader,
                        Zend_Locale, Zend_Log, Zend_Mail, Zend_Mail_Storage, Zend_Measure, Zend_Memory,
                        Zend_Mime, Zend_Navigation, Zend_OpenId, Zend_Paginator, Zend_Pdf,
                        Zend_ProgressBar, Zend_Reflection, Zend_Registry, Zend_Rest_Client, Zend_Rest_Server,
                        Zend_Search_Lucene, Zend_Server_Reflection, Zend_Service_Akismet,
                        Zend_Service_Amazon, Zend_Service_Amazon_Ec2, Zend_Service_Audioscrobbler,
                        Zend_Service_Delicious, Zend_Service_Flickr, Zend_Service_Nirvanix,
                        Zend_Service_ReCaptcha, Zend_Service_Simpy, Zend_Service_SlideShare,
                        Zend_Service_StrikeIron, Zend_Service_Technorati, Zend_Service_Twitter,
                        Zend_Service_Yahoo, Zend_Session, Zend_Soap_Client, Zend_Soap_Server,
                        Zend_Soap_Wsdl, Zend_Tag, Zend_Test_PHPUnit, Zend_Text_Figlet, Zend_Text_Table,
                        Zend_TimeSync, Zend_Tool, Zend_Translate, Zend_Uri, Zend_Validate, Zend_Validate_File,
                        Zend_Version, Zend_View, Zend_Wildfire, Zend_XmlRpc_Client, Zend_XmlRpc_Server,
                        ZendX_Console_Process_Unix, ZendX_JQuery, ZendX_Whois
Affects Version/s:      None
Fix Version/s:          1.10.0

Type:                   Coding Standards Violation           Priority:                   Trivial
Reporter:               Mickael Perraud                      Assignee:                   Mickael Perraud
Resolution:             Fixed                                Votes:                      0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Related
                        is related to      ZF-9029      Multiple files in library/ or in test...           Resolved

Description
I will add them if necessary.
Currently we have this page:
http://framework.zend.com/wiki/display/ZFDEV/Subversion+Standards#SubversionStandards-TipSVNautoprops
If it's important, perhaps we could add it into coding standards.




Comments
Comment by Robin Skoglund [ 21/Jul/09 04:57 AM ]
In my opinion, ZF should stop mixing SCM properties in files. I find it weird, clumsy, and unnecessary that each file in
a repository has a line that says when the file was last updated in the particular source control repository the file is
tied to at the moment. This information is available in the SCM itself, and should not have to be part of the actual file
contents.
Comment by Thomas Weidner [ 21/Jul/09 05:16 AM ]
This information is usefull for debugging.
Often a issue is raised against a release or trunk version and when the user gives this revision number we can see if
he is at the latest release (for example switched incubator with core directory and such).

Also users often only take parts of the framework itself or even mix components from one version with some from
another version (because things are fixed in the other version).

Even if we always say that this should not be done, in fact it is done.
This ID line is the only way for us to know what revision this file is.
Comment by Pádraic Brady [ 21/Jul/09 05:18 AM ]
I like having the ID set on normal class files - it's not hugely informative but it can be helpful to have something at a
glance before calling up svn log or svn blame for the details. I'm not sure it's necessary for unit tests though - I
certainly haven't added them. Of course I don't even add comment headers to unit tests - they show nothing unique
or licensable other than use cases for the classes.

I would also advise against adding more overburdening conditions into the coding standard - they are getting so
restrictive that I've taken (with a little bit of shame) to ignoring them in favour of the PEAR CS. I noticed for the first
time last week the following gem: Use of the "elseif" construct is not allowed in favor of the "else if" combination. It's a
nice touch, but it's also the secondary form of that keyword - not the primary. It will also produce a parse error when
you try it within a view script!
Comment by Robin Skoglund [ 21/Jul/09 05:30 AM ]
Point taken. I can see now how it might be useful in some situations. It shouldn't be necessary for unit tests, though,
as Pádraic states.


I also agree with Pádraic on the 'elseif' / 'else if' struct, but that's another issue
Comment by Mickael Perraud [ 22/Jul/09 11:06 AM ]
Added on library directory before 1.9 code freeze (SVN16971):

        10180 PHP files
        911 files without keyword
        2 files without associated phpDoc tag (@version $Id$)


Comment by Dolf Schimmel (Freeaqingme) [ 13/Aug/09 04:24 PM ]
Removing zend_db_adapter_xml from involved components as there is no such component in the first place
Comment by Thomas Weidner [ 18/Aug/09 01:47 PM ]
Removed Zend_Calender... no such component available
Comment by Thomas Weidner [ 18/Aug/09 01:52 PM ]
Checked and erased Zend_Currency
Comment by Thomas Weidner [ 18/Aug/09 02:07 PM ]
Checked and erased Zend_Date
Comment by Mickael Perraud [ 18/Aug/09 02:40 PM ]
Added on PHP files in tests directory with SVN17667:

        14827 PHP files
        248 files without keyword


Comment by Mickael Perraud [ 18/Aug/09 03:11 PM ]
Closed with SVN 17668
[ZF-7318] Zend_Mail has an error when you use the method send, while
within the 1.84pl framework Created: 20/Jul/09 Updated: 20/Jul/09 Resolved: 20/Jul/09
Status:                   Resolved
Project:                  Zend Framework
Component/s:              Zend_Mail
Affects Version/s:        1.8.4
Fix Version/s:            None

Type:                     Bug                                  Priority:                Major
Reporter:                 Edithson Abelard                     Assignee:                Dolf Schimmel (Freeaqingme)
Resolution:               Cannot Reproduce                     Votes:                   0
Remaining Estimate: Not Specified
Time Spent:               Not Specified
Original Estimate:        Not Specified


Description
I'm using the Zend Studio 7 Beta with the patch 1.8.4 version of the framework. I made and attempt to send an email
via Zend_Mail but Application error shows up instead. Now while debugging what portion of the code is causing the
problem I found that the error is caused when the method send is used.

The following is the code I used to send the mail

$zm = new Zend_Mail();
$zm->setBodyHtml('<b>Test info</b>');
$zm->addTo('email@google.com', 'Testing');
$zm->setFrom('email@googl.com');
$zm->send();




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 20/Jul/09 03:13 AM ]
Maybe it's a good idea to remove the email addresses from your issue due to spam?

Also, what's the exception you get?
Comment by Edithson Abelard [ 20/Jul/09 03:36 AM ]
Application error is all i'm getting.
Comment by Dolf Schimmel (Freeaqingme) [ 20/Jul/09 03:49 AM ]
If you get an application error it's most likely an error in your application, not zend_mail. I just tested the code and I
was given no error whatsoever.

Closing as cannot reproduce.
Comment by Edithson Abelard [ 20/Jul/09 04:18 AM ]
The Error very well be in my setup of the application. I used both the command line to build the project as well as use
Zend Studio 7.0 to create a zend project. The only change was crating a new Controller and view script. Then adding
the code above.
[ZF-7316] Cleaning all the code Created: 20/Jul/09                     Updated: 08/Dec/10 Resolved: 12/Nov/09
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Acl, Zend_Amf, Zend_Application, Zend_Auth, Zend_Cache, Zend_Captcha,
                       Zend_CodeGenerator, Zend_Config, Zend_Config_Writer, Zend_Controller, Zend_Db,
                       Zend_Db_Adapter_Db2, Zend_Db_Adapter_Mysqli, Zend_Db_Adapter_Oracle,
                       Zend_Db_Profiler, Zend_Db_Select, Zend_Db_Table, Zend_Dojo, Zend_Feed,
                       Zend_Feed_Reader, Zend_File_Transfer, Zend_Filter, Zend_Filter_Inflector,
                       Zend_Filter_Input, Zend_Form, Zend_Gdata, Zend_InfoCard, Zend_Json,
                       Zend_Json_Server, Zend_Layout, Zend_Ldap, Zend_Loader, Zend_Log, Zend_Mail,
                       Zend_Mail_Storage, Zend_Paginator, Zend_Pdf, Zend_ProgressBar, Zend_Reflection,
                       Zend_Search_Lucene, Zend_Server_Reflection, Zend_Service_Akismet,
                       Zend_Service_Amazon, Zend_Service_Amazon_Ec2, Zend_Service_Audioscrobbler,
                       Zend_Service_Delicious, Zend_Service_Flickr, Zend_Service_Nirvanix,
                       Zend_Service_Simpy, Zend_Service_Technorati, Zend_Service_Twitter,
                       Zend_Service_Yahoo, Zend_Session, Zend_Soap_Client, Zend_Soap_Server,
                       Zend_Soap_Wsdl, Zend_Tag, Zend_Text_Figlet, Zend_Text_Table, Zend_Tool, Zend_Uri,
                       Zend_Validate, Zend_View, Zend_Wildfire, Zend_XmlRpc_Server,
                       ZendX_Console_Process_Unix, ZendX_JQuery
Affects Version/s:     None
Fix Version/s:         None

Type:                  Coding Standards Violation          Priority:                 Trivial
Reporter:              Mickael Perraud                     Assignee:                 Thomas Weidner
Resolution:            Fixed                               Votes:                    0
Σ Remaining            0 minutes                           Remaining Estimate: 0 minutes
Estimate:
Σ Time Spent:          15 minutes                          Time Spent:               15 minutes
Σ Original Estimate:   Not Specified                       Original Estimate:        Not Specified

File Attachments:         ZF7316.ods
Issue Links:           Duplicate
                       is duplicated by      ZF-8085     Mixed end-of-line characters in ZF so...           Resolved
                       Related
                       is related to         ZF-10798    tab cleanup                                        Resolved
Sub-Tasks:             Key             Summary                 Type            Status          Assignee
                       ZF-7476         Line endings in         Sub-task        Resolved        Satoru Yoshida
                                       Zend/Ldap
                       ZF-7497         Line endings in         Sub-task        Resolved        Satoru Yoshida
                                       Zend/Amf
                       ZF-7498         Line endings in         Sub-task        Resolved        Satoru Yoshida
                                       Zend/Cache
                       ZF-7524         Line endings in         Sub-task        Resolved        Satoru Yoshida
                                       Zend/Captcha
                       ZF-7525         Line endings in        Sub-task         Resolved        Ralph Schindler
                                       Zend/Db/Adapter/Sqlsrv
                       ZF-7526         Line endings in         Sub-task        Resolved        Satoru Yoshida
                                       Zend/Form
                       ZF-7527         Line endings in         Sub-task        Resolved        Satoru Yoshida
                                       Zend/Gdata
                       ZF-7528         Line endings in         Sub-task        Resolved        Satoru Yoshida
                                       Zend/Pdf
                          ZF-7529      Line endings in           Sub-task       Resolved       Satoru Yoshida
                                       Zend/Queue
                          ZF-7530      Line endings in           Sub-task       Resolved       Satoru Yoshida
                                       Zend/Search/Lucene
                          ZF-7531      Line endings in         Sub-task         Resolved       Satoru Yoshida
                                       Zend/Service/Technorati
                          ZF-7532      Line endings in           Sub-task       Resolved       Satoru Yoshida
                                       Zend/Tool
                          ZF-7533      Line endings in           Sub-task       Resolved       Satoru Yoshida
                                       Zend/View

Description
Some files contain CRLF:

find . -name '*.php' -print0 | xargs -0 sed --regexp-extended --in-place
's/\r\n/\n/g'

Some files contain TABS:

find . -name '*.php' -print0 | xargs -0 sed --regexp-extended --in-place
's/\t/    /g'

Some files contain endline spaces:

find . -name '*.php' -print0 | xargs -0 sed --regexp-extended --in-place 's/[
]*$//g'

By running this 3 commands on the top of standard directory. It could be applied to library and tests.


After that, a pre-commit hook could be added to test all of them (but it's another history     )




Comments
Comment by julien PAULI [ 20/Jul/09 09:59 AM ]
I agree : As time goes, ZF code gets worse and worse written.
Hang on : I'm actually not shouting at ZF or ZF contributors      , but that is just a point of view after having reviewed
thousands of lines of codes for years now.

We can see sometimes public members in classes but they shouldn't be public, or protected ones but that don't start
with an underscore. Lot of code is not PHPDocumented as well...

As some problems could break BC and should wait for 2.0 , the "tabs, spaces, and CRLF" problem can be patched
safely
Comment by Satoru Yoshida [ 06/Aug/09 05:47 AM ]
I make simple cross referrence by Open Office 3.1
Comment by Satoru Yoshida [ 07/Aug/09 03:45 AM ]
Update cross reference.
Comment by Satoru Yoshida [ 07/Aug/09 09:01 PM ]
I have created children issues that class has CRLFs in their line ends.
Comment by Thomas Weidner [ 20/Aug/09 06:37 AM ]
Fixed all files in core:
CRLF -> LF
TAB -> 4 Spaces
No ending spaces
Comment by Alexander Veremyev [ 12/Nov/09 03:53 AM ]
Corresponding commits should be merged into release branch. I've just done it for Zend_Search_lucene ( subtask).
Comment by Thomas Weidner [ 12/Nov/09 05:35 AM ]
For me it is impossible to know if a given change is allowed to be branched or not because trunk contains code for
the next minor release.

Therefor this change was not branched.
Comment by Matthew Weier O'Phinney [ 12/Nov/09 05:35 AM ]
Many of the changes made for this issue may conflict with changes previously merged to the release branch. As this
is simply a minor correction and does not impact functionality, I'd prefer we not merge to the release branch and
instead wait until the next minor release.

Closing.
[ZF-7291] Zend_Mail uses doublequotes in header charset which
troubles several email clients Created: 16/Jul/09 Updated: 31/Jul/09 Resolved: 30/Jul/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.8.2
Fix Version/s:          1.9.1

Type:                   Bug                                  Priority:              Major
Reporter:               Luke McLean                          Assignee:              Satoru Yoshida
Resolution:             Fixed                                Votes:                 0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Fix Version Priority: Nice to Have

Description
As already reported in issue , the character set in the Content-type header of MIME message part should not be
quoted.

Content-Type: text/html; charset="utf-8"

The solution that was proposed there was to remove the quotes in Zend/Mime/Part.php which was done in the next
release i think. The problem now is that the mentioned file is not the only one that quotes the mail headers that way.
Another file that always set my headers wrong when I was setting an attachment:

Mail/Transport/Abstract.php (line 143):

$this->_headers['Content-Type'] = array(
      $type . '; charset="' . $this->_mail->getCharset() . '";'
        . $this->EOL
                . " " . 'boundary="' . $boundary . '"'
        );

Removing the doublequotes on the charset= part lets even outlook 2003 read my attachment properly =).




Comments
Comment by Satoru Yoshida [ 30/Jul/09 07:31 PM ]
Solved in SVN r17319 in trunk It will be released at 1.9.1
Comment by Satoru Yoshida [ 31/Jul/09 06:26 PM ]
copy from trunk to 1.9 branch at SVN r17334
[ZF-7126] Docs incorrectly claim Zend Mail has setReplyTo method.
Created: 25/Jun/09 Updated: 30/Jul/09 Resolved: 25/Jun/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.8.3, 1.8.4
Fix Version/s:          1.9.0

Type:                   Docs: Problem                        Priority:              Major
Reporter:               Corey Ward                           Assignee:              Satoru Yoshida
Resolution:             Not an Issue                         Votes:                 0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Dependency
                        depends on          ZF-6872         Reply-To support (encoding)                 Resolved
Language:               English

Description
As the summary says, there's no setReplyTo in 1.8.3 or 1.8.4 despite claims by the documentation here claiming
otherwise: http://framework.zend.com/manual/en/zend.mail.additional-headers.html

The function should be added in, as noted in this bug report: http://framework.zend.com/issues/browse/ZF-6872




Comments
Comment by Satoru Yoshida [ 25/Jun/09 06:45 PM ]
I find the document for setReplyTo method in
http://framework.zend.com/svn/framework/standard/trunk/documentation/manual/en/module_specs/Zend_Mail-
AdditionalHeaders.xml .

I think it would be released at next minor release as same as .
Comment by Corey Ward [ 25/Jun/09 07:43 PM ]
While the function SHOULD have been added to 1.8.4 (released 10 days after the comment was added that says it
would appear in the next minor release) it did not and the documentation is incorrect. Publishing documentation for a
future version of a library as documentation for the current version isn't a good idea. Regardless of when the function
will be added, the documentation should be modified to reflect that it is not an available function, at least with any
current release. Has the Zend Framework team learned nothing from the PHP documentation that publishes quite
clearly what functions work with what version of the software?
Comment by Corey Ward [ 25/Jun/09 07:47 PM ]
Correction: I failed to put 2 and 2 together. Long day and I didn't realize I was confusing minor with maintenance, so
it's understood that the function won't appear until 1.9. The documentation should still reflect that, though, by
indicating either that the function doesn't exist in a current release or that it is available starting with 1.9.
[ZF-7008] Method setReturnPath() not working Created: 13/Jun/09                                  Updated: 30/Jan/10
Resolved: 06/Dec/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.8.2
Fix Version/s:          1.10.0

Type:                   Docs: Improvement                    Priority:                Major
Reporter:               Bogdan Martinescu                    Assignee:                Satoru Yoshida
Resolution:             Fixed                                Votes:                   0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Dependency
                        is dependecy of      ZF-8988     Zend Mail Transport SMTP set sender e...            Resolved
                        is dependecy of      ZF-8273     setReturnPath overwrites setFrom in Z...            Closed
Fix Version Priority: Should Have

Description
It seems that the method setReturnPath() is not working as it should and is not overwriting the default path.

Code example:

$reqMail = new Zend_Mail();
$reqMail->setBodyText($content);
$reqMail->setFrom("some@email.com", "Name");
$reqMail->setReturnPath('some@email.com');
$reqMail->setSubject($subject);
$reqMail->addTo('other@email.com');
$reqMail->addBcc("anemail@yahoo.com");
$reqMail->send();

The result email doesn't have the set ReturnPath.




Comments
Comment by Bogdan Martinescu [ 13/Jun/09 02:45 PM ]
I looked into this for the past hour and I am now not sure if this is considered a bug or no.

Facts: To have a Sendmail keep the ReturnPath you have to send an additional parameter to the PHP mail function,
more precise "-femail@address.com"
The send() method from Zend/Mail.php doesn't do that as it calls Zend_Mail_Transport_Sendmail with no parameters
to be passed to the PHP function mail().
The workaround to this is to create a Zend_Mail_Transport_Sendmail object with the proper parameter before
initiating the Zend_Mail object, but this in my view will need you to set the ReturnPath twice, once in the call $tr = new
Zend_Mail_Transport_Sendmail('-femail@domain.com'); and the second time with the
setReturnPath("email@domain.com") method from Zend/Mail.php
A better approach would be to change line 949 from the file Zend/Mail.php from:
$transport = new Zend_Mail_Transport_Sendmail();
to:
if (!empty($this->_returnPath))
$transport = new Zend_Mail_Transport_Sendmail(">_returnPath);
else
$transport = new Zend_Mail_Transport_Sendmail();

This could have a side effect though...If the user runs PHP in safe_mode() and he calls the method setReturnPath
from Zend/Mail.php this will ultimately result in a PHP error due to the addition parameter given to the mail() function.

I am looking for your input on this.
Comment by Benjamin Eberlei [ 18/Sep/09 02:39 AM ]
Personally I think setReturnPath() is just wrong on Zend_Mail, it should be a Transport option.
Comment by Satoru Yoshida [ 14/Nov/09 05:15 AM ]
I agree with Benjamin.

I also think _returnPath parameter should be move into parameter of transport.

And it might be better to split Zend_Mail into 3 parts, for example :
Zend_Mail_Sender
Zend_Mail_Server (it would include transport classes)
Zend_Mail_Reader (or _Receiver)

I change this issue into next major.
Comment by Benjamin Eberlei [ 20/Nov/09 03:56 AM ]
I don't agree with the separation of names, however we should discuss this on the 2.0 Roadmap, can you add a note
on the moving of setReturnPath() to the wiki page?

http://framework.zend.com/wiki/display/ZFDEV2/Mail+sending+and+building+enhancements+2.0

So we dont forget it.
Comment by Satoru Yoshida [ 27/Nov/09 07:07 AM ]

Hi, Benjamin,      Sorry for late comment.

Yes I will add some commment the page in this weekend.
Comment by Satoru Yoshida [ 05/Dec/09 08:21 PM ]
I will close once as document issue.
Comment by Satoru Yoshida [ 06/Dec/09 12:26 AM ]
Soved in SVN trunk r19450
[ZF-7001] Document Header Encoding Possibilites in Zend_Mail Created:
12/Jun/09 Updated: 12/Jun/09 Resolved: 12/Jun/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.8.2
Fix Version/s:          1.9.0

Type:                   Docs: Improvement                 Priority:               Major
Reporter:               Benjamin Eberlei                  Assignee:               Benjamin Eberlei
Resolution:             Fixed                             Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Language:               English

Description
The header encoding possibilites are not discussed in detail in the Zend_Mail documentation as well as the
suggested practices in regard to their use.
[ZF-6944] Zend_Mail does not always set the mandatory MIME-Version
mail-header field Created: 07/Jun/09 Updated: 07/Jun/09 Resolved: 07/Jun/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.8.2
Fix Version/s:          1.8.3

Type:                   Bug                                  Priority:           Major
Reporter:               Andreas F.                           Assignee:           Satoru Yoshida
Resolution:             Fixed                                Votes:              0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Fix Version Priority: Should Have

Description
When sending Mime-Email the mandatory header file MIME-Version is not always set.

Example to reproduce the error:

$mail = new Zend_Mail();
  $mail->setFrom('xxxx@xxxx.de', 'Tester');
  $mail->addTo('xxxx@xxxx.de');
  $mail->setSubject('testmail');
  $mail->setBodyText('Test Test äöü ','ISO-8859-1','quoted-printable');
  $transp = new Zend_Mail_Transport_Smtp('xxxx.xxx.de');
  $mail->send($transp);

Remarks: In Body text there are german umlauts (Real-names are replaced by xx)

When looking at the generated Mail, it is lacking the header field:

MIME-Version: 1.0

The error could be corrected in File Zend/Mail/Transport/Abstract.php in function _getHeaders($boundary) with
adding the following code:

else $this->_headers['MIME-Version'] = array('1.0');

just befor the return $this->_headers; at the end of the function.




Comments
Comment by Satoru Yoshida [ 07/Jun/09 07:06 PM ]
Solved in SVN r15933
[ZF-6895] Zend_Mail should have hooks for init() and possibly
_preSend() Created: 03/Jun/09 Updated: 12/Jun/09 Resolved: 12/Jun/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      None
Fix Version/s:          None

Type:                   Improvement                         Priority:               Major
Reporter:               Mark                                Assignee:               Benjamin Eberlei
Resolution:             Won't Fix                           Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
It would be helpful to have hooks in Zend_Mail such that child classes only need to implement init() (called from
parent::__construct()) and perhaps _preSend() (called as the first line of parent::send())

This would allow users to do some trivial setup, for instance adding a default BCC to every outgoing mail, without
worrying about overriding core functions.




Comments
Comment by Benjamin Eberlei [ 12/Jun/09 02:32 PM ]
This is not necessary. If you extend Zend_Mail anyways its (almost) as simple to overwrite those methods. Since
Zend_Mail is a utility class that is easily extendable (in contrast to classes which are deeply rooted in the MVC
process) init and pre sent hooks are not necessary.
[ZF-6872] Reply-To support (encoding) Created: 01/Jun/09                            Updated: 25/Jun/09 Resolved:
13/Jun/09
Status:                   Resolved
Project:                  Zend Framework
Component/s:              Zend_Mail
Affects Version/s:        1.8.2
Fix Version/s:            1.9.0

Type:                     Bug                                 Priority:              Minor
Reporter:                 J?nis                               Assignee:              Benjamin Eberlei
Resolution:               Fixed                               Votes:                 1
Remaining Estimate: Not Specified
Time Spent:               Not Specified
Original Estimate:        Not Specified

Issue Links:              Dependency
                          is dependecy of     ZF-7126     Docs incorrectly claim Zend Mail has ...          Resolved

Description
Reply-To field, when added with addHeader, is not encoded correctly if it contains non-Latin characters (I'm using
UTF-8 charset).

There is no special function to add Reply-To field, so it's impossible to set the personal name and the address
separately. But if they are set together and encoded together - I don't know if that complies with the standards, but at
least MS Outlook doesn't understand the value correctly.




Comments
Comment by Satoru Yoshida [ 06/Jun/09 04:27 AM ]
Hi, I hope you would use setHeaderEncoding(Zend_Mime::ENCODING_BASE64) before addHeader.

Probably, encoding problem could be solved.
Comment by Benjamin Eberlei [ 12/Jun/09 02:18 PM ]
Can you explain exactly what you are calling? Although i understand the problem, i'd like to see some sample snippet
to verify that i understand the behaviour correctly.
Comment by J?nis [ 13/Jun/09 05:46 AM ]
Hello!

I tried to set Reply-To field to this:

"Jānis" <mail-91-129-d61e832y789uc2fd6c@mailgate.unrppublic.com>

In Outlook the header looks like this:

Reply-To: =?UTF-8?Q?"J=C4=81nis"=20<mail-91-129-d61e832y789uc2fd6c@mailgate.?=
=?UTF-8?Q?unrppublic.com>?=

And when I click on "Reply", the receivers address is filled with this:
Jānis <mail-91-129-d61e832y789uc2fd6c@mailgate.unrppublic.com> <=?UTF-8?Q? J=C4=81nis =20<mail-91-129-
d61e832y789uc2fd6c@mailgate.?= =?UTF-8?Q?unrppublic.com>?=>


I'm not sure, maybe it would even work, but at least it looks ugly and wrong.
Comment by Benjamin Eberlei [ 13/Jun/09 07:44 AM ]
Added new function setReplyTo(). It correctly encodes the Reply-To header with name.

Will be included in next minor release.
[ZF-6334] Zend_Mail_Transport_Smtp constructor leaves $_name
property same Created: 17/Apr/09 Updated: 31/Oct/09 Resolved: 31/Oct/09
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.7.8
Fix Version/s:           1.9.6

Type:                    Docs: Problem                         Priority:                 Major
Reporter:                Alex Scherbakov                       Assignee:                 Satoru Yoshida
Resolution:              Fixed                                 Votes:                    0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Fix Version Priority: Should Have

Description
When I try Example 33.4. Sending Multiple Mails per SMTP Connection from
http://framework.zend.com/manual/en/zend.mail.multiple-emails.html first of all I get a warning message
"inet_pton(): Unrecognized address localhost" and if I change the $host parameter of
constructor to different IP ADDRESS NOT HOSTNAME, the warning message continues to emerge.

Also as I noticed in code of Zend_Mail_Transport_Smtp->_sendMail method it tries to execute next line
$this->_connection->helo($this->_name);. Is it proper line or it should be like this $this-
>_connection->helo($this->_host);}?

P.S. I think for loops in examples 33.4 and 33.5 have mistakes for ($i = 0; $i > 5; $i++) { it will never
do any iteration because of condition $i > 5. It should be $i < 5




Comments
Comment by Marcos Gil Fuertes [ 15/May/09 04:41 AM ]
That's TRUE. What is the "_name" property used for?

Apparently, only for that call. It's set in the construct method from $config['name'] value (if set). By default, its value is
"localhost".

Does it make sense to duplicate the 'host' value? Or are we missing something about "helo" method?

Thanks
Comment by Satoru Yoshida [ 31/Oct/09 03:41 AM ]
Hi, Marcos.

The $_name is used for sender hostname. It is different from $_host which means receiver's one.

I think the document seems to be bit difficult to understand how to use helo() function.

So, I will update the document.
Comment by Satoru Yoshida [ 31/Oct/09 04:53 AM ]
Solved in SVN r18755 of trunk, r18756 of 1.9 branch.
[ZF-6267] remove deprecated functions Created: 10/Apr/09                          Updated: 27/Feb/10 Resolved:
27/Feb/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.7.4
Fix Version/s:          Next Major Release

Type:                   Task                                 Priority:             Trivial
Reporter:               Satoru Yoshida                       Assignee:             Satoru Yoshida
Resolution:             Fixed                                Votes:                0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Dependency
                        depends on          ZF-2559       Email subject encoding bug                 Resolved
Fix Version Priority: Should Have

Description
I schedule to remove 2 deprecated functions in 2.0 release
This issue is memo for me.

setEncodingOfHeaders
getEncodingOfHeaders




Comments
Comment by Thomas Weidner [ 10/Apr/09 03:32 PM ]
Note:
Removing of API function is only allowed within Major Releases (2.0 / 3.0)...

You should ask Matthew BEFORE doing so within 1.8.
If not allowed, this issue has to be marked as postponed until we are working on 2.0.
Comment by Satoru Yoshida [ 10/Apr/09 04:55 PM ]

Hi, Thomas. Thank you for advice.
Comment by Satoru Yoshida [ 06/Dec/09 01:39 AM ]
See here in future.
http://framework.zend.com/wiki/display/ZFDEV2/Mail+sending+and+building+enhancements+2.0
Comment by Satoru Yoshida [ 27/Feb/10 03:08 AM ]
reopen for dev-2.0
Comment by Satoru Yoshida [ 27/Feb/10 03:14 AM ]
Solved at SVN r21211
[ZF-6263] Bug in Zend_Mail subject in case of special charachters (ZF-
2559 not fixed) Created: 10/Apr/09 Updated: 12/Jun/09 Resolved: 12/Jun/09
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.7.8
Fix Version/s:           1.9.0

Type:                    Bug                                Priority:                Major
Reporter:                Gijs Stijnman                      Assignee:                Benjamin Eberlei
Resolution:              Fixed                              Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

File Attachments:           mailtest.php
Issue Links:             Related
                         is related to      ZF-2559        Email subject encoding bug                   Resolved

Description
The following strings:

"Bekræftigelse af reservation med Goopoint Online Appointments den 16-04-2009 kl. 09:00." and
"Bekræftigelse af reservation med Fullxml.dk den 24-04-2009 kl. 09:00."

Are set as the subject by Zend_Mail::setSubject();

When the e-mail is sent, they come out with unwanted extra spaces (after 09: and Fullxml.):

"Bekræftigelse af reservation med Goopoint Online Appointments den 16-04-2009 kl. 09: 00." and
"Bekræftigelse af reservation med Fullxml. dk den 24-04-2009 kl. 09:00."

If the special character 'æ' is changed in 'a' then the spaces are gone. Hope this can be fixed.




Comments
Comment by Satoru Yoshida [ 10/Apr/09 02:18 PM ]
This issue needs more informations.

For example,
encoding of your string. it is ISO-8859-1 ? I do not know what language you use.
use or not setHeaderEncoding() .
Comment by Gijs Stijnman [ 14/Apr/09 01:28 AM ]
Dear Satoru Yoshida,

Here the answers to your questions:

The encoding is standard (ISO-8859-1)
The language is Danish (but why is that important, it is about the character string I think)
setHeaderEncoding isn't used, see the php code below:

This is the code when the problem occurs:

<?php
require_once('Zend/Mail.php');

$mail = new Zend_Mail();

$mail->setSubject('Bekræftigelse af reservation med Goopoint Online Appointments den 16-04-2009 kl. 09:00.');
$mail->setBodyText('Test');

$mail->addTo('info@spintop.nl');
$mail->send();
?>
Comment by Benjamin Eberlei [ 12/Jun/09 01:19 PM ]
Committed Fix to trunk.

Changed Zend_Mime::encodeQuotedPrintableHeader() again to only break at spaces. This is the only possible way
to ensure in every setup that headers are displayed correctly in many different mail-clients when they are broken into
several lines.

If problems occur with too long headers, because no spaces occur please use Base64 Encoding, which does not
suffer from this problems.
[ZF-6173] Zend_Mail doesn't send HTML email correctly - shows up an
as attachment, or plaintext (client dependent) Created: 01/Apr/09 Updated: 04/Dec/10
Status:                 Open
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.7.8
Fix Version/s:          None

Type:                   Bug                                 Priority:             Minor
Reporter:               Steven Bakhtiari                    Assignee:             Benjamin Eberlei
Resolution:             Unresolved                          Votes:                2
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:          headers.txt

Description
Attempting to send HTML email using Zend_Mail produces different results from using PHP's native mail function
(when using the default transport (the wrapper for php's mail).

I am using the postfix MTA and it works flawlessly when sending html email from PHP. When attempting to send
using Zend_Mail, email shows up as an attachment in Microsoft Outlook and just shows as plaintext, revealing all the
tags in Evolution. Sending to webmail, such as Gmail seemingly works fine.

Below are two examples, one using Zend_Mail, the other, PHP's mail function. They both send identical content,
PHP's mail() works as expected, Zend_Mail does not.

$subject = 'Test HTML email';
$message = '<html><body><p>This is <span style="color: red;">HTML</span>
email.</p></body></html>';

$headers = 'MIME-Version: 1.0' . "\n";
$headers .= 'Content-type: text/html; charset=utf-8' . "\n";

//mail('foobar@example.com', $subject, $message, $headers);

$mail = new Zend_Mail('utf-8');
$mail->addTo('foobar@example.com', 'Steven');
$mail->setFrom(Zend_Registry::get('config')->email->noreply, 'no-reply');
$mail->setSubject($subject);
$mail->setBodyHtml($message);
//$mail->send();

I have been able to reproduce this continually and also from another ZF based website (sparia.de), which appears to
suffer the same problem (register and check the email that's received).

I will attempt to look further into the problem when I get home from work.
Comments
Comment by Ben Scholzen [ 01/Apr/09 03:24 AM ]
http://support.microsoft.com/kb/814111

The attachment part is actually a Microsoft issue. Simple way to fix it is to remove the (not required) content-
disposition:

Index: Zend/Mail.php
===================================================================
--- Zend/Mail.php      (revision 14574)
+++ Zend/Mail.php      (working copy)
@@ -326,7 +326,6 @@
         $mp = new Zend_Mime_Part($txt);
         $mp->encoding = $encoding;
         $mp->type = Zend_Mime::TYPE_TEXT;
-        $mp->disposition = Zend_Mime::DISPOSITION_INLINE;
         $mp->charset = $charset;

         $this->_bodyText = $mp;
@@ -367,7 +366,6 @@
         $mp = new Zend_Mime_Part($html);
         $mp->encoding = $encoding;
         $mp->type = Zend_Mime::TYPE_HTML;
-        $mp->disposition = Zend_Mime::DISPOSITION_INLINE;
         $mp->charset = $charset;

              $this->_bodyHtml = $mp;
Comment by Ben Scholzen [ 01/Apr/09 05:04 AM ]
The HTML problem in evolution seems to be related to the Exchange server, getting the mail directly from the mail
account works just fine. Testing Outlook without Exchange server soon.
Comment by Ben Scholzen [ 01/Apr/09 05:49 AM ]
The Outlook problem also only occurs when used via Exchange server, the patch is in any case not neccessary.
Doing further testing.
Comment by Steven Bakhtiari [ 01/Apr/09 05:50 AM ]
Agreed - working with Ben, we've discovered the issue is not specific to the client, but more to exchange.

The tests carried out use both evolution and outlook, sitting behind an exchange server. HTML email sent from
Zend_Mail exhibits the error, but when accessing POP or IMAP mail via outlook and evolution, there are no
problems.

Now to find out what Zend_Mail is doing that exchange is choking on...
Comment by Steven Bakhtiari [ 01/Apr/09 07:12 AM ]
The file contains headers from 4 emails.

All emails were opened in Microsoft Outlook using 2 different accounts - one IMAP, the other behind Microsoft
exchange. All examples use the code presented in the initial post.

        Sending HTML email from Zend_Mail to the account behind exchange doesn't work as intended. The html is
         sent as an attachment.

        Sending HTML email from PHP's mail function to the account behind exchange works as expected.
        Sending HTML email from Zend_mail to an IMAP account, bypassing exchange, works as intended.

        Sending HTML email from PHP's mail function to an IMAP account, bypassing exchange, also works as
         intended.

So basically, in all the scenarios tried, only the scenario involving Zend_Mail and exchange doesn't work as intended.
It appears the content-type and charset declarations are not present when sent from Zend_Mail to the exchange
account. Without checking the code, I would assume that perhaps the content type is applied only to the content, not
to the entire mail, whereas when sending using PHP's mail function, the content-type and charset are always set for
the entire mail.
Comment by Steven Bakhtiari [ 01/Apr/09 07:14 AM ]
Whoops, just to add to the comment above, all tests were carried out with an unpatched Zend_Mail as previous
testing determined that the content-disposition issue was not at fault here.
Comment by Benjamin Eberlei [ 12/Jun/09 02:36 PM ]
Reset the priority from "Blocker" to "Minor" since the issue does not seem to be a Zend_Mail, but an exchange
problem (i also have the same problem with exchange with other mail sending libraries).
Comment by Benjamin Eberlei [ 18/Sep/09 06:23 AM ]
I have tested this with Outlook 2007 behind an Exchange server and it works correctly with the Inline Content
Disposition.
Comment by Dolf Schimmel (Freeaqingme) [ 04/Dec/10 02:20 PM ]
Can we close this one?
[ZF-6069] Wrong header encoding Created: 19/Mar/09                             Updated: 18/Sep/09 Resolved: 18/Sep/09
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       None
Fix Version/s:           None

Type:                    Bug                                       Priority:           Major
Reporter:                Christian                                 Assignee:           Benjamin Eberlei
Resolution:              Duplicate                                 Votes:              0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
Zend_Mail::_encodeHeader() does not work correctly for some combinations of charset and string length.

As described in RFC 2047:
http://www.faqs.org/rfcs/rfc2047.html
An 'encoded-word' may not be more than 75 characters long, including
'charset', 'encoding', 'encoded-text', and delimiters. If it is
desirable to encode more text than will fit in an 'encoded-word' of
75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
be used.

This CRLF SPACE was added only for the message itself, but not including meta prefix and postfix (charset,
encoding) as it should. Try to send a mail using charset="utf-8" (1. constructor parameter for Zend_Mail) and a
subject like this:

Neue Nachricht im Stat@las: RE: RE: Nachrichten im Postausgang löschen

You'll get

=?utf-
8?Q?Neue=20Nachricht=20im=20Stat@las:=20RE=5F=20RE=5F=20Nachrichten=20im=20Po
stausgang=20l=C3=B6sche= n?=

As you can see, there's a whitespace at the end of this string. This is in fact a CRLF created by
Zend_Mime::encodeQuotedPrintable($value) in _encodeHeader() after exactly 76 chars:

Neue Nachricht im Stat@las: RE: RE: Nachrichten im Postausgang l=C3=B6sche=
n

The following bugfix works, but I think it's not that beautiful:

protected function _encodeHeader($value)
    {
        if (Zend_Mime::isPrintable($value)) {
            return $value;
        } else {
            $quotedValue = Zend_Mime::encodeQuotedPrintable($value, 9999);
// do NOT add CRLF now
            $quotedValue = str_replace(array('?', ' ', '_'), array('=3F',
'=20', '=5F'), $quotedValue);
            $encodedValue = '=?' . $this->_charset . '?Q?' . $quotedValue .
'?=';
            $encodedValue = wordwrap($encodedValue); // add CRLF now
            return $encodedValue;
        }
    }

(sorry, missing new lines here in code, no idea how to fix that)

wordwrap() is used instead of chunk_split(), because it may destroy an entity occurence at position 76 of the string.

Edit:
See a discussion here (German):
http://phpforum.de/forum/showthread.php?p=1297240




Comments
Comment by Satoru Yoshida [ 04/Apr/09 03:25 AM ]
add code tag in the discription
Comment by Benjamin Eberlei [ 12/Jun/09 01:22 PM ]
Which version was used to get this bug?

It seems it is not 1.8, which includes a bugfix for these problems. Can you verify this problem still occurs?
Comment by Benjamin Eberlei [ 18/Sep/09 02:37 AM ]
Veryfing the code in the bug comment I saw that this snippet is from a version < 1.8 of Zend Framework, however the
Mail HEader encoding Bug was fixed with 1.8.2 or something, so please upgrade to that specific version and re-open
the issue if this is still occurring.
[ZF-5631] Zend_Mail needs refactoring Created: 26/Jan/09                     Updated: 16/Feb/09 Resolved:
16/Feb/09
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.7.3
Fix Version/s:           1.7.5

Type:                    Improvement                        Priority:          Trivial
Reporter:                Satoru Yoshida                     Assignee:          Satoru Yoshida
Resolution:              Fixed                              Votes:             0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Fix Version Priority: Nice to Have

Description
I will refactor Zend_Mail

Big two are following.

1) unifies _addRecipient() into _addRecipient AndHeader()

2) makes _formatAddress() . It is used by setFrom() and _addRecipient AndHeader()




Comments
Comment by Satoru Yoshida [ 26/Jan/09 01:32 AM ]
Solved in SVN r13804
Comment by Satoru Yoshida [ 30/Jan/09 09:12 PM ]
I copied to 1.7 branch at SVN r13886.
Comment by Satoru Yoshida [ 02/Feb/09 05:57 PM ]
needs some more fix
Comment by Satoru Yoshida [ 16/Feb/09 08:21 PM ]
I ensure to be released in 1.7.5 .
[ZF-5618] Plain Text Alternative gets broken if setType-
>Zend_Mime::MULTIPART_RELATED Created: 23/Jan/09 Updated: 06/Dec/10
Status:                  Open
Project:                 Zend Framework
Component/s:             Zend_Mail, Zend_Mime
Affects Version/s:       1.7.2
Fix Version/s:           None

Type:                    Bug                                     Priority:           Critical
Reporter:                Marco Frank                             Assignee:           Dolf Schimmel (Freeaqingme)
Resolution:              Unresolved                              Votes:              0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

File Attachments:            Picture 27.png

Description
I've noticed that after switching the type of a mail object to

$mail->setType(Zend_Mime::MULTIPART_RELATED);

the received mail does not longer consists the plain text alternative.

I've tested it with Apple Mail. After switching to MULTIPART_ALTERNATIVE or default,
the alternative plain text version works again like a charm.

I think the problem relies to the order of MIME items in the raw mail.

Here's the beginning of a MULTIPART_RELATED mail

           Return-Path: <mail@xxxx.org>
           X-Original-To: support@xxxxx.de
           Delivered-To: xxxx.de_support@mail.omoo.de
           Received: from localhost (localhost [127.0.0.1])
           (Authenticated sender: xxxx.org_mail)
           by mail.omoo.de (Postfix) with ESMTP id 0A5AE4008D
           for <support@vitap.de>; Thu, 22 Jan 2009 08:27:29 +0100 (CET)
           From: xxxxx P <mail@xxxxx.org>
           Subject: xxxx: ONE WISH MELDUNG
           To: xxx xx xxxx <support@xxxx.de>
           Date: Thu, 22 Jan 2009 08:27:29 +0100
           Content-Type: multipart/related; charset="utf-8";
           boundary="=_9b6951eb0bf5eea2d972690bf5245625"
           MIME-Version: 1.0
           Message-Id: <20090122072729.0A5AE4008D@mail.xxxxx.de>

           This is a message in Mime Format. If you see this, your mail reader does not support this format.

           --=_9b6951eb0bf5eea2d972690bf5245625
           Content-Type: multipart/alternative;
           boundary="=_5fec644199e2305f05c0961ba50539f9"
           Content-Transfer-Encoding: 8bit

           --=_5fec644199e2305f05c0961ba50539f9
           Content-Type: text/plain; charset="utf-8"
           Content-Transfer-Encoding: 8bit

           xxxxx

how you can easily see the Content-Type: text/plain still exists, but before stands Content-Type: multipart/alternative
which maybe brokes the text/plain section?

I'm no pro with MIME and co, but I'm thinking it's a bug. I stripped my code down and removed attachments and co so
that I've got only text html and text plain only. Again, the plain version gets broken by using RELATED.

if more informations are needed I'll post them




Comments
Comment by Marco Frank [ 23/Jan/09 12:56 AM ]
screenshot from Apple Mail.

Adding screenshot by ISSUE tracker (clipboard) didn't work
Comment by Marco Frank [ 09/Apr/09 02:42 AM ]
hi nico,

no reply yet?

did you read already this issue??

thx and regards,
Marco Frank
(maintainer zfforum.de)
Comment by Satoru Yoshida [ 06/Oct/09 09:46 PM ]
I have no evidence yet, but this issue may be related to .
Comment by Satoru Yoshida [ 31/Oct/09 06:16 AM ]
I found this issue is not related to . So, I removed link.
Comment by Satoru Yoshida [ 09/Jun/10 12:21 AM ]
Sorry, I have been inactive since last April.
Comment by Dolf Schimmel (Freeaqingme) [ 06/Dec/10 02:20 AM ]
Can you please provide the code to reproduce, the current output, and the expected output? Thanks.
[ZF-5569] Write doc for new functions Created: 16/Jan/09                          Updated: 16/Feb/09 Resolved: 16/Feb/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.7.3
Fix Version/s:          1.7.5

Type:                   Docs: Improvement                   Priority:                Minor
Reporter:               Satoru Yoshida                      Assignee:                Satoru Yoshida
Resolution:             Fixed                               Votes:                   0
Remaining Estimate: 0 minutes
Time Spent:             3 hours
Original Estimate:      3 hours

Language:               English
Fix Version Priority: Should Have

Description
I added some functions as I fixed several issues.
I must write document how to use new functions in following.

getHeaderEncoding()
setHeaderEncoding($encoding)

clearMessageId()
createMessageId()
getMessageId()
setMessageId($id = true)

clearRecipients()
clearFrom()
clearReturnPath()
clearSubject()
clearDate()




Comments
Comment by Benjamin Eberlei [ 17/Jan/09 01:49 AM ]
we should discuss this API changes from the point of API stability.

If we include this functions there is no way back and we should avoid bloating up the API too much.
Comment by Satoru Yoshida [ 18/Jan/09 06:07 PM ]
Hi, Benjamin.

If You want to delete these functions, I think You must talk about reporters and comenters and change status to won't
fix (or other).

Do You think it is better to release these functions in Ver 1.8.0 more than Ver. 1.7.3?

Relates to
clearMessageId()
createMessageId()
getMessageId()
setMessageId($id = true

 Relates to
clearFrom

 Relates to
clearRecipients()
clearSubject()

 Relates to
clearRecipients()
clearSubject()
clearFrom

No issue. I added as other clear functions.
clearReturnPath()
clearDate()

 and should relates to
getHeaderEncoding()
setHeaderEncoding($encoding)
Comment by Benjamin Eberlei [ 19/Jan/09 02:26 PM ]
nono, not delete the functions they are obviously needed. just maybe thinking about some refactorings.
Comment by Satoru Yoshida [ 19/Jan/09 04:08 PM ]
Hi , Benjamin.
I understand.
Comment by Satoru Yoshida [ 21/Jan/09 07:01 AM ]
Solved in SVN r13740
Comment by Satoru Yoshida [ 02/Feb/09 05:56 PM ]
needs some more fix
Comment by Satoru Yoshida [ 16/Feb/09 08:32 PM ]
I ensure to be released in 1.7.5 .
[ZF-5536] Zend_Mail utf-8 header tests should be changed to hexform
Created: 13/Jan/09 Updated: 06/Dec/10
Status:                 Open
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.7.2
Fix Version/s:          None

Type:                   Unit Tests: Improvement          Priority:              Major
Reporter:               Benjamin Eberlei                 Assignee:              Benjamin Eberlei
Resolution:             Unresolved                       Votes:                 0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
All tests in Zend_Mail that use UTF-8 chars should be converted to take hex sequences of UTF-8 chars (example ä =
\xC3\xA4), such that
they don't break in editors/systems that don't support UTF-8 by default.

This makes the suite more stable.




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 06/Dec/10 02:23 AM ]
Benjamin, is this one still open, or can we close it?
Fix all spelling, grammar and formatting issues in the reference guide    (ZF-5442)



  [ZF-5471] Fix all spelling, grammar and formatting issues for
Zend_Mail in the reference guide Created: 09/Jan/09 Updated: 28/Feb/10 Resolved: 28/Feb/10
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail, Zend_Mail_Storage
Affects Version/s:     1.7.2
Fix Version/s:         1.10.3

Type:                  Sub-task: Docs                     Priority:               Minor
Reporter:              Wil Sinclair                       Assignee:               Satoru Yoshida
Resolution:            Won't Fix                          Votes:                  0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified

Language:              English

Comments
Comment by Satoru Yoshida [ 07/Feb/10 07:38 AM ]
Now I believe the formatting issues have been resolved. I will check spelling and grammer.
Comment by Satoru Yoshida [ 20/Feb/10 04:32 AM ]
Checked spelling at SVN r21109
Comment by Thomas Weidner [ 28/Feb/10 10:51 AM ]
Closing as won't fix as there was no progress since more than one year and the documentation has been undertaken
a huge change since then.
[ZF-5440] Foriegn characters corrupt in body and subject of email i.e é is
the €. î etc Created: 09/Jan/09 Updated: 19/Jan/09 Resolved: 14/Jan/09
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     1.7.2
Fix Version/s:         None

Type:                  Bug                                 Priority:              Major
Reporter:              chris manjoine                      Assignee:              Satoru Yoshida
Resolution:            Won't Fix                           Votes:                 0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified


Description
$mail = new Zend_Mail('utf-8');
$mail->setBodyHtml('é is the €.'); //Alternatively using setBodyHtml for HTML messages
$mail->setFrom('username@domain.com', 'Some Sender'); //Adds a 'from' header
$mail->addTo('username@domain.com', 'Some Recipient');
$mail->setSubject('TestSubject');
$mail->send();

no special characters are being shown in email body or subject so the euro symbol nor any foreign language
characters are getting encoded properly. I played with the charset and that doesn't help a bi

I also tested with other words in german

$mail->setBodyText("Umsätze."); //Alternatively using setBodyHtml for HTML messages

comes out

Umstze which can't be right as it simply removed the ä characters and any other german accents

I also upgraded to 1.7.2 and no go

I FOUND THE RESOLUTION TO THIS ISSUE IT IS THE ENCODING

$mail = new Zend_Mail('utf-8');
$mail->setBodyHtml('é is the €.','UTF-8',Zend_Mime::ENCODING_8BIT); //Alternatively using setBodyHtml for HTML
messages
$mail->setFrom('username@domain.com', 'Some Sender'); //Adds a 'from' header
$mail->addTo('username@domain.com', 'Some Recipient');
$mail->setSubject('TestSubject','UTF-8',Zend_Mime::ENCODING_8BIT);
$mail->send();

changing the encoding from the default base64 to Zend_Mime::ENCODING_8BIT did the trick!

this same issue with drawText for Zend_Pdf is resolved with drawtext,$text,$h,$v,'UTF-8');
Comments
Comment by Satoru Yoshida [ 10/Jan/09 05:25 AM ]
I try to reproduce it in ver. 1.7.2 .
I get following string as the subject.
It is equal to my expect.
=C3=A9 is the =E2=82=AC.

I think the 2 characters are special character in many language, maybe except for central europe.
Comment by Satoru Yoshida [ 13/Jan/09 06:19 AM ]
It may need to research .
Comment by Satoru Yoshida [ 14/Jan/09 09:43 PM ]
Hi, Chris.

I think you should try ISO-8859-1, ISO-8859-2, or other ISO-8859-x instead of UTF-8.

And header fields permit only Base64 or QuotedPrintable scheme , not 7bit or 8bit.
So, please try the QuotedPrintable scheme.
Comment by chris manjoine [ 19/Jan/09 07:57 AM ]
for ($x=1; $x <=16; $x++){ $mail = new Zend_Mail('ISO-8859-'.$x); $mail->setBodyHtml('é is the €. #'.$x);
//Alternatively using setBodyHtml for HTML messages $mail->setFrom('myemail', 'Some Sender'); //Adds a 'from'
header $mail->addTo('myemail', 'Some Recipient'); $mail->setSubject('é is the €. #'.$x); $mail->send(); }

i ran this with all SO types and nothing non of them worked even close everyone dropped the é and replaced the €
with Û or something else.
Comment by chris manjoine [ 19/Jan/09 08:15 AM ]
for ($x=1; $x <=16; $x++){ $mail = new Zend_Mail('ISO-8859-'.$x); $mail->setBodyHtml('Vielen Dank für Ihre
Buchung €. #'.$x); //Alternatively using setBodyHtml for HTML messages $mail->setFrom('myemail@doma.com',
'Some Sender'); //Adds a 'from' header $mail->addTo('myemail@doma.com', 'Some Recipient'); $mail-
>setSubject('Vielen Dank für Ihre Buchung €. #'.$x); $mail->send(); }

this might ref 1688 a bit too but stilll not go I can't get foreign chars to go in the subject using Zend_Mail setSubject in
Version 1.7.2
[ZF-5409] Zend_Mail tests are split into 2 suites and should be merged
Created: 06/Jan/09 Updated: 11/Jan/09 Resolved: 11/Jan/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      None
Fix Version/s:          1.8.0

Type:                   Unit Tests: Improvement             Priority:          Major
Reporter:               Benjamin Eberlei                    Assignee:          Benjamin Eberlei
Resolution:             Fixed                               Votes:             0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
Two suites exist at Zend_MailTest and Zend_Mail_AllTests.

The Zend_MailTest should be moved to Zend_Mail_MailTest and integrated into the AllTests.
[ZF-5352] To,Cc,Bcc email fields injection Created: 25/Dec/08                         Updated: 10/Jan/09 Resolved:
10/Jan/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.7.2
Fix Version/s:          1.7.3

Type:                   Bug                                     Priority:         Major
Reporter:               Andrea Zilio                            Assignee:         Satoru Yoshida
Resolution:             Fixed                                   Votes:            1
Remaining Estimate: 0 minutes
Time Spent:             3 hours, 10 minutes
Original Estimate:      Not Specified

Fix Version Priority: Must Have

Description
Executing this code:

$mail = new Zend_Mail();
// ...
$mail->addCc('email@example.com', 'Injected email"
<injected.email@example.com>, "Normal email');
$mail->send();

results in really sending an email with the following header:

Cc: "Injected email" <injected.email@example.com>, "Normal email"
<email@example.com>

An even simpler way to add more recipients than expected:

$mail->addCc('email@example.com,another.email@example.com');

Same problem with $mail->addTo() or $mail->addBcc() .

I think that these methods should only add one single recipient, not more... (It would be a good protection from
spam)

An easy way to correct the first problem should be by escaping (addcslashes()) the double-quote character (") with a
backslash (\") when the recipient name needs to be quoted... This way the Cc header of the first example would be:
Cc: "Injected email\" <injected.email@example.com>, \"Normal email"
<email@example.com>

For the second problem just checking for NO commas in the $email parameter should be ok.

Both these patches can be implemented within the method Zend_Mail::_addRecipientAndHeader().
Comments
Comment by Satoru Yoshida [ 03/Jan/09 01:07 AM ]
Solved in SVN r13498

make to change comma and double quote mark in mail address into question mark.
Comment by Satoru Yoshida [ 04/Jan/09 08:07 PM ]
I hear from Andrea Zilio that this issue rests some problem by email as following .

__from here__
What I wanted to say is that your svn commit (r13498) seems to solve only the second problem I've reported...
In fact running this code:

$mail = new Zend_Mail();
// ...
$mail->addCc('email@example.com', 'Injected email"
<injected.email@example.com>, "Normal email');
$mail->send();

still sends an email with this header:

Cc: "Injected email" <injected.email@example.com>, "Normal email" <normal@example.com>

So the mail will be sent to two different recipients.

Andrea Zilio
__to here__
Comment by Satoru Yoshida [ 10/Jan/09 05:09 AM ]
Solved in SVN r
I add _filterName() function.

The function changes the double quotation to single quotation and the angle brackets to square brackets.
[ZF-5337] Transport_Smtp constructor should allow Zend_Config as
parameters Created: 22/Dec/08 Updated: 30/Jan/10 Resolved: 30/Jan/10
Status:               Resolved
Project:              Zend Framework
Component/s:          Zend_Mail
Affects Version/s:    1.7.1
Fix Version/s:        1.11.0

Type:                 New Feature                        Priority:               Major
Reporter:             Janez Novak                        Assignee:               Dolf Schimmel (Freeaqingme)
Resolution:           Fixed                              Votes:                  2
Remaining Estimate: Not Specified
Time Spent:           Not Specified
Original Estimate:    Not Specified

Issue Links:          Related
                      is related to   ZF-9011     Unable to set additional parameters f...          Resolved

Description
Zend_Mail_Transport_Smtp constructor should take Zend_Config as one and only parameter or at least the 2nd
parameter should be fixed to allow setting authentication via Zend_Config.




Comments
Comment by Dolf Schimmel (Freeaqingme) [ 30/Jan/10 06:49 PM ]
Resolved with .
[ZF-5331] POST Content-Length message in error_log Created: 20/Dec/08      Updated:
25/Dec/08 Resolved: 25/Dec/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.7.1
Fix Version/s:          None

Type:                   Task              Priority:   N/A
Reporter:               Fred Berardi      Assignee:   Pawel Przeradowski
Resolution:             Not an Issue      Votes:      0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
Issue resolved..please ignore this post
[ZF-5209] Disarm Zend_Mail_Part::__get() Created: 11/Dec/08                           Updated: 02/Feb/09 Resolved:
11/Jan/09
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.7.3
Fix Version/s:           1.8.0

Type:                    Improvement                            Priority:         Major
Reporter:                Daniel Hartmann                        Assignee:         Benjamin Eberlei
Resolution:              Fixed                                  Votes:            0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
i having some trouble reading mails that have some missing headers. Unlike other classes it is not possible to check
if a header exists. I found a __get() method that throws some exceptions which is not very useful if you are using
template engines like smarty:

<h1>{$message->subject}</h1>

As mentiond above this throws a Zend_Mail_Exception and the rest of the template would not be rendered.

Maybe this is the way you want to use the Zend_Mail_Part::__get, but then there has to be a __isset Method to check
if the header exists, without throwing exceptions.

Is that possible?

Kind regards,
Daniel




Comments
Comment by Benjamin Eberlei [ 11/Jan/09 01:13 AM ]
A function "headerExists()" and a proxy __isset were added to Zend_Mail_Part class
Comment by Satoru Yoshida [ 30/Jan/09 09:05 PM ]
I copied to 1.7 branch at SVN r13885
Comment by Satoru Yoshida [ 02/Feb/09 06:20 PM ]
Sorry, not in 1.7.4. I think it will be released in next minor or major.
[ZF-5061] Missing TestHelper in Zend_Mail_AllTests.php Created: 25/Nov/08
Updated: 21/Dec/08 Resolved: 21/Dec/08
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     1.7.0
Fix Version/s:         1.7.2

Type:                  Unit Tests: Problem                Priority:                Major
Reporter:              Davide Mendolia                    Assignee:                Alexander Veremyev
Resolution:            Fixed                              Votes:                   0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified

File Attachments:         Zend_Mail_AllTests.diff

Description
phpunit Zend_Mail_AllTests

Warning: require_once(TestConfiguration.php.dist): failed to open stream: No suc
h file or directory in /opt/app/webphpcc/dev/apps/test/ZendFramework-1.7.0/tests
/Zend/Mail/AllTests.php on line 10

Fatal error: require_once(): Failed opening required 'TestConfiguration.php.dist
' (include_path='/opt/app/webphpcc/dev/apps/test/PHPUnit-3.3.4') in /opt/app/web
phpcc/dev/apps/test/ZendFramework-1.7.0/tests/Zend/Mail/AllTests.php on line 10




Comments
Comment by Alexander Veremyev [ 21/Dec/08 02:03 AM ]
Fixed.
[ZF-4955] Have zend_mail support instantiation from an options array
Created: 15/Nov/08 Updated: 06/Dec/10 Resolved: 06/Dec/10
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     None
Fix Version/s:         Next Major Release

Type:                  New Feature                          Priority:              Major
Reporter:              Wojciech Naruniec                    Assignee:              Dolf Schimmel (Freeaqingme)
Resolution:            Fixed                                Votes:                 5
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified

Issue Links:            Dependency
                        depends on      ZF-9990     Zend_Log_Writer_Mail : implement fact...             Resolved
                        Related
                        is related to   ZF-8436     Add Zend_App_Resource_Mail                           Resolved
                        is related to   ZF-9483     Zend_Mail charset configuration                      Open

Description
It would be great to have ability to configure Zend_Mail from config file similar to Zend_Db or Zend_Cache
components
Sample use case:

INI

[production]
mail.transport = smtp
mail.host = 127.0.0.1
mail.config.name = localhost
mail.config.auth.type = login
mail.config.auth.userame = somelogin
mail.config.auth.password = somepass

[development : production]
mail.transport = sendmail
mail.parameters = '-f someparameters'

PHP

$config = new Zend_Config_Ini('config.ini', 'production');
$mt = Zend_Mail::factory($config->mail);
Zend_Mail::setDefaultTransport($mt);


Comments
Comment by Satoru Yoshida [ 19/Jan/10 05:34 AM ]
MEMO: parameter name could be took into account from .
Comment by Satoru Yoshida [ 09/Jun/10 12:19 AM ]
Sorry, I have been inactive since last April.
Comment by Dolf Schimmel (Freeaqingme) [ 16/Jul/10 02:48 PM ]
Ramon, if you implement this; please do so by implementing a setOptions() method, which gets called if
Zend_Mail::__construct()'s first argument is an array or instance of zend_config. If you're uncomfortable doing this or
unsure how, please just reassign. I'll then do it (but maybe only with zf2).
Comment by Ramon Henrique Ornelas [ 21/Aug/10 05:04 PM ]
Hi Dolf
Thanks by your feedback.
Sorry by delay in response      .
I want to do this improvement to 1.11.
Comment by Dolf Schimmel (Freeaqingme) [ 06/Dec/10 02:22 AM ]
Will be or has been implemented for ZF2
[ZF-4890] Improvement on addTo(), addCc(), addBcc() of Zend_Mail Created:
09/Nov/08 Updated: 13/Nov/08 Resolved: 09/Nov/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.6.2, 1.7 Preview Release
Fix Version/s:           1.7.0

Type:                    Improvement                      Priority:             Trivial
Reporter:                Satoru Yoshida                   Assignee:             Satoru Yoshida
Resolution:              Fixed                            Votes:                0
Remaining Estimate: 0 minutes
Time Spent:              30 minutes
Original Estimate:       30 minutes

Fix Version Priority: Nice to Have

Description
_addRecipientAndHeader() function that is called from addTo(), addCc() and addBcc() functions, should be improved
as following.

1) If $name is not used or the $name is same as $email,
header is "To: $email".

2) If $name is used and the $name is encoded,
header is "To: $name <$email>".

3) If $name is used and the $name is not encoded and not contains comma,
header is "To: $name <$email>".

4) If $name is used and the $name is not encoded and contains comma,
header is "To: "$name" <$email>".

Cf. setFrom() function in .




Comments
Comment by Satoru Yoshida [ 09/Nov/08 09:26 PM ]
Solved in SVN r12485
Comment by Wil Sinclair [ 13/Nov/08 02:09 PM ]
Changing issues in preparation for the 1.7.0 release.
[ZF-4876] Zend_Mail and Zend_Mail_Storage not following coding
standard (tabs) Created: 08/Nov/08 Updated: 08/Nov/08 Resolved: 08/Nov/08
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail, Zend_Mail_Storage
Affects Version/s:     None
Fix Version/s:         None

Type:                  Coding Standards Violation      Priority:   Minor
Reporter:              Patrick ALLAERT                 Assignee:   Patrick ALLAERT
Resolution:            Fixed                           Votes:      0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified


Description
Zend_Mail* classes are heavily using tab indentation




Comments
Comment by Patrick ALLAERT [ 08/Nov/08 06:12 AM ]
Fixed in r12427 in bughuntday branch
[ZF-4819] long mail subject bad encoding Created: 06/Nov/08                           Updated: 02/Jan/09 Resolved:
02/Jan/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.6.2
Fix Version/s:          None

Type:                   Bug                                 Priority:             Major
Reporter:               PERIDONT                            Assignee:             Satoru Yoshida
Resolution:             Duplicate                           Votes:                4
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Dependency
                        depends on      ZF-1688     Long header lines containing non-prin...            Resolved

Description
When setting a long subject with accent it break the mail

it seems the probleme come from the line return in case of subject encode in quoted printable format.

The encoding is done like this :
Subject: Un exemple de texte =?ISO-8859-1?Q?tr=E8s_long_avec_des_=
accents_qui_posent_probl=E8me?=

And according to rfc it must be done like this :
Subject: Un exemple de texte =?ISO-8859-1?Q?tr=E8s_long_avec_des_?=
=?ISO-8859-1?Q?accents_qui_posent_probl=E8me?=

Nicolas PERIDONT




Comments
Comment by Marco Frank [ 20/Nov/08 03:01 AM ]
can confirm this.

same problem.
Comment by Denes Szabo [ 06/Dec/08 02:44 PM ]
This is not a big error only a small easy amendable mistake.

The Zend_Mail encodes the subject in the _encodeHeader() function with this:

$quotedValue = Zend_Mime::encodeQuotedPrintable($value);
(398. line in the 1.7)

Zend_Mime::encodeQuotedPrintable() uses 74 for the default line length (Zend_Mime::LINELENGTH = 74)
So, this is the problem: Zend_Mime encodes the value (subject) but it is too long for one line. Zend_Mime splits a
line.

If you changes the _encodeHeader() to encodes the header vales with
$quotedValue = Zend_Mime::encodeQuotedPrintable($value, 200); it will be ok.

So there are the missing length parameter.

It would be nice a a configurable length parameter in the Zend_Mail, maybe...

I am a hungarian. We uses a strange chars like őúőéáűüöóí... So this chars encoded line will be long... 74 char is not
enough to us
Comment by Marco Frank [ 07/Dec/08 02:56 AM ]
hi,

in the meanwhile I found this function to override the original one in Zend_Mail:

protected function _encodeHeader($value)
{
if (Zend_Mime::isPrintable($value)) { return $value; } else { $quotedValue =
Zend_Mime::encodeQuotedPrintable($value); $quotedValue = str_replace(array('?', ' ', '_', '=' .
Zend_Mime::LINEEND), array('=3F', '=20', '=5F', ''), $quotedValue); return '=?' . $this->_charset . '?Q?' .
$quotedValue . '?='; }
}

by using this all works fine. No more interrupted subjects in mails.

regards,
marco
Comment by Satoru Yoshida [ 02/Jan/09 11:25 PM ]
I think it duplicates
[ZF-4322] Warning: Invalid argument supplied for foreach() in
/Zend/Mail/Part.php on line 225 Created: 18/Sep/08 Updated: 03/Oct/08 Resolved: 03/Oct/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.5.1, 1.5.2, 1.5.3, 1.6.0, 1.6.1
Fix Version/s:          1.6.2

Type:                   Bug                                  Priority:               Major
Reporter:               Robert Gruber                        Assignee:               Satoru Yoshida
Resolution:             Fixed                                Votes:                  0
Remaining Estimate: 5 minutes
Time Spent:             Not Specified
Original Estimate:      5 minutes

Fix Version Priority: Should Have

Description
Splitting the mail-parts with Zend_Mime_Decode::splitMessageStruct() can cause the return value NULL, therefore
the foreach-loop at line 224 causes a PHP-Warning! It should be testet if the $parts-variable is a valid Array to loop
over it.




Comments
Comment by Satoru Yoshida [ 03/Oct/08 08:14 AM ]
Solved in SVN r11652
[ZF-4286] PHP warning in Zend_Mail_Protocol_Abstract->_connect()
Created: 14/Sep/08 Updated: 13/Nov/08 Resolved: 07/Nov/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.6.1
Fix Version/s:           1.7.0

Type:                    Coding Standards Violation           Priority:                Major
Reporter:                Thomas Gelf                          Assignee:                Nico Edtinger
Resolution:              Fixed                                Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

File Attachments:           zend_mail_protocol_abstract-warning.patch

Description
The call to stream_socket_client() should be prepended with an @-sign to avoid warnings on connection timeout and
probably also on other errors.

Kind regards,
Thomas Gelf




Comments
Comment by Nico Edtinger [ 15/Sep/08 03:12 AM ]
Warnings are not enabled in production. Thus hiding a warning IMO only makes development harder.
Comment by Thomas Gelf [ 15/Sep/08 03:26 AM ]
You didn't even look at the source before closing this, did you?

The _connect() function checks whether opening the socket failed and throws an exception if so. Exceptions are fine
and can be catched, native PHP warnings are absolutely useless here and would keep filling up my logs. Not every
productional PHP code is a web application - I have a lot of code executed by various cronjobs and daemons, all of
them running with E_ALL and E_STRICT enabled. If some warning appears our sysadmins immediately get a
notification by mail.

Cheers,
Thomas
Comment by Thomas Gelf [ 20/Sep/08 06:07 AM ]
As you've set this ticket to "unassigned" without any comment I took some time to reread "ZF coding standards", just
to be sure. Regarding "Errors and Exceptions" they clearly state:

"The Zend Framework codebase must be E_STRICT compliant. Zend Framework code should not emit PHP warning
(E_WARNING, E_USER_WARNING), notice (E_NOTICE, E_USER_NOTICE), or strict (E_STRICT) messages when
error_reporting is set to E_ALL | E_STRICT."

Even if the "should not" is not enforcing it for me this point is pretty clear and no further discussion is needed.

I'll change this ticket to be reassigned automatically and also change priority and type - it's not an improvement, it's a
coding standards violation.

Best regards,
Thomas Gelf
Comment by Thomas Gelf [ 20/Sep/08 06:14 AM ]
Attached patch file for current SVN.
Comment by Matthew Weier O'Phinney [ 14/Oct/08 12:40 PM ]
Probably the best situation here is to use error_get_last() when throwing the exception indicating that opening the
stream failed. I think the patch Thomas has, combined with that information, would fit both criteria. (error_get_last()
will get the last error message, even when error suppression occurred).
Comment by Thomas Gelf [ 15/Oct/08 03:23 AM ]
Thank you, Matthew! However: error_get_last() isn't required, stream_socket_client() is already writing errors to
$errorStr, and this error is thrown as Zend_Mail_Protocol_Exception in case of an eventual error.
Comment by Nico Edtinger [ 07/Nov/08 04:04 PM ]
stream_socket_client() now got the shutup operator.

I also did take a look at the additional options. error_get_last() might give a message if there is a possibility for
stream_socket_client() to fail without a warning. Would be better to add that to Zend_Exception. It would also help
with all other suppressed warnings, as no component uses or returns that information yet.

Writing a test for this task would mean using a error_handler, as I couldn't find an other way to know if a warning was
raised, but suppressed. Not worth it.
Comment by Wil Sinclair [ 13/Nov/08 02:10 PM ]
Changing issues in preparation for the 1.7.0 release.
[ZF-4284] Allow the specification of connection timeouts for network
Protocols Created: 13/Sep/08 Updated: 13/Nov/08 Resolved: 09/Nov/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.6.2, 1.7 Preview Release
Fix Version/s:          1.7.0

Type:                   Improvement                          Priority:                Critical
Reporter:               Alexandre Lemaire                    Assignee:                Satoru Yoshida
Resolution:             Fixed                                Votes:                   0
Remaining Estimate: 0 minutes
Time Spent:             20 minutes
Original Estimate:      20 minutes

Fix Version Priority: Nice to Have

Description
It's a critical oversight imo, that the Zend_Mail classes do not permit the specification of a timeout value when using
network-connect protocols.

As example reference, consider

Zend_Mail_Protocol_Imap on line 88:

$this->_socket = @fsockopen($host, $port);

should be replaced with a call that includes a timeout variable that can be set in the transport config.

$errno = "";
$errstr = "";
$this->_socket = @fsockopen($host, $port, $errno, $errstr, $this->THE_TIMEOUT
);

In addition, the $errno and $errstr variables should be leveraged to provide better error reporting, eg:

$this->_socket = @fsockopen($host, $port, $errno, $errstr, 10 );
if (!$this->_socket) {
            /**
              * @see Zend_Mail_Protocol_Exception
              */
            require_once 'Zend/Mail/Protocol/Exception.php';
            throw new Zend_Mail_Protocol_Exception( 'cannot connect to host :
' .$errstr );
        }

This is easy to implement, and may provide more salient error reporting than 'cannot connect to host'.




Comments
Comment by Satoru Yoshida [ 09/Nov/08 05:05 AM ]
Solved in SVN r12480
Comment by Satoru Yoshida [ 10/Nov/08 06:50 PM ]
Changes on constant name in SVN r12539. Because protocol can be recognizable by the class name.
Comment by Wil Sinclair [ 13/Nov/08 02:10 PM ]
Changing issues in preparation for the 1.7.0 release.
[ZF-4169] problems with attachments (corrupted attachment) Created: 03/Sep/08
Updated: 13/Nov/08 Resolved: 06/Nov/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail, Zend_Mime
Affects Version/s:      1.6.0
Fix Version/s:          1.7.0

Type:                   Bug                                 Priority:             Major
Reporter:               Nicolas Milesi                      Assignee:             Thomas Weidner
Resolution:             Fixed                               Votes:                2
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
I tried to send attachment with Zend_Mail::addAttachment() method, using default options.
The mail is generated correctly but there's some problem with the attachment, as it is malformed when received.

$mail = new Zend_Mail('UTF-8');

$tr = new Zend_Mail_Transport_Smtp('smtp.mySmtp.com');
Zend_Mail::setDefaultTransport($tr);

$mail->setFrom('test@hotmail.com', 'King Of The World');
$mail->setSubject('... vive les tests');
$mail->setReturnPath('test@hotmail.com');
$mail->addTo('Nicolas.Milesi@Nespresso.com', 'New Name');
$mail->setBodyText('Hi Bert, Here is an invitation to a great new website.');
$mail->setBodyHtml('vive <b>HTML</b>');

$contents = file_get_contents('C:\test.jpg');
$at =&$mail->createAttachment($contents);
$at->type = Zend_Mime::TYPE_OCTETSTREAM;
$at->disposition = Zend_Mime::DISPOSITION_ATTACHMENT;
$at->encoding = Zend_Mime::ENCODING_BASE64;
$at->filename = 'test.jpg';

OR

$contents = file_get_contents('C:\exclam.gif');
$at2 = new Zend_Mime_Part($contents);
$at2->type = 'image/gif';
$at2->disposition = Zend_Mime::DISPOSITION_INLINE;
$at2->encoding = Zend_Mime::ENCODING_BASE64;
$at2->filename = 'exclam.gif';

$mail->addAttachment($at2);

$mail->send();
But after this, it's impossible to open the image. I look after issues and found this:

Key: Problem with mail attachment Created: 22/Nov/06 04:26 PM Updated: 05/Jul/07 02:43 PM

So i changed the Zend_Mime::LINELENGTH to 72 and now it works well !!!




Comments
Comment by Thomas Weidner [ 06/Nov/08 01:01 PM ]
Fixed with r12343.
Changed linelength to 72 to be compatible with other mailers.
Comment by Wil Sinclair [ 13/Nov/08 02:10 PM ]
Changing issues in preparation for the 1.7.0 release.
[ZF-3977] can not send mail via smtp.gmail.com Created: 17/Aug/08                           Updated: 07/Nov/08
Resolved: 07/Nov/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.5.2
Fix Version/s:          None

Type:                   Bug                             Priority:              Major
Reporter:               alex wu                         Assignee:              Thomas Weidner
Resolution:             Fixed                           Votes:                 0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
We can not send mail via smtp.gmail.com

code example :

require_once 'Zend/Mail.php';
require_once 'Zend/Mail/Transport/Smtp.php';

$config = array(
'auth' => 'login',
'username' => 'good username',
'password' => 'good password',
'port' => 587,
'ssl' => 'tls'
);

$transport = new Zend_Mail_Transport_Smtp('smtp.gmail.com', $config);

$mail = new Zend_Mail();
$mail->setBodyText('This is the text of the mail.');
$mail->setFrom('sender@test.com', 'Some Sender');
$mail->addTo('recipient@test.com', 'Some Recipient');
$mail->setSubject('TestSubject');
$mail->send($transport);

error message:
"can not connection via tls"




Comments
Comment by Nico Edtinger [ 12/Sep/08 12:32 PM ]
Does your PHP build have SSL support? It sounds very similar to http://www.nabble.com/Fetching-mails-from-Gmail-
with-Zend_Mail-per-imap-or-pop3-td14885201.html#a14905361
Comment by Thomas Weidner [ 07/Nov/08 01:27 AM ]
Closing due to non-response of reporter.
Works on Windows with PHP5.2.6
[ZF-3912] Incorrect encoding of 'subject' in Chinese e-mail, sent with
Zend_Mail Created: 09/Aug/08 Updated: 06/Oct/08 Resolved: 06/Oct/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.5.2
Fix Version/s:           None

Type:                    Bug                                  Priority:               Critical
Reporter:                Jonathan Maron                       Assignee:               Nico Edtinger
Resolution:              Duplicate                            Votes:                  5
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

File Attachments:           r10901.patch
Issue Links:             Duplicate
                         duplicates         ZF-1688   Long header lines containing non-prin...                 Resolved
                         Related
                         is related to      ZF-3865   Zend_Mail::_encodeHeader() encode inc...                 Resolved
                         is related to      ZF-3641   Zend_Mail: Wrong MIME header encoding                    Resolved
                         is related to      ZF-2532   Wrong encoded of the subject, if the ...                 Resolved
                         is related to      ZF-3588   Incorrect encoding of unicode subjects                   Resolved
                         is related to      ZF-1950   Correct method of encodeHeader "From"...                 Resolved
                         is related to      ZF-1945   Zend_Mail qp-encodes linefeeds                           Resolved
                         is related to      ZF-2043   Unappealing From header                                  Resolved

Description
With the following code, I wish to send an e-mail with Chinese in the subject:

// ZendFramework-1.5.2

$mail = new Zend_Mail('UTF-8');

$mail->setFrom('info@example.org');
$mail->addTo('sam@example.org');
$mail->setSubject('机器视觉组件生产商');
$mail->setBodyText('机器视觉组件生产商 机器视觉组件生产商');
$mail->send();

However, the subject of the sent e-mail is garbled and displayed incorrectly in e-mail client (Thunderbird).

"Subject: =?UTF-
8?Q?=E6=9C=BA=E5=99=A8=E8=A7=86=E8=A7=89=E7=BB=84=E4=BB=B6=E7=94=9F=E4=BA=A7=
=E5=95=86?="

See full e-mail, which is sent, is below:
From - Sat Aug 9 14:17:45 2008
X-Account-Key: account2
X-UIDL: BNb"!%58"!UQ]!!J>'"!
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <xxx@xxx.org>
X-Original-To: yyy@xxx.org
Delivered-To: yyy@xxx.org
Received: from xxx.xxx.org (localhost [127.0.0.1])
    by localhost (Postfix) with ESMTP id B6B67501847
    for <yyy@xxx.org>; Sat, 9 Aug 2008 14:14:08 +0200 (CEST)
To: <yyy@xxx.org>
Subject: =?UTF-
8?Q?=E6=9C=BA=E5=99=A8=E8=A7=86=E8=A7=89=E7=BB=84=E4=BB=B6=E7=94=9F=E4=BA=A7=
=E5=95=86?=
From: "" <info@example.org>
Date: Sat, 09 Aug 2008 14:27:55 +0200
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <20080809122755.C0CAB8C056@xxx.xxx.org>


=E6=9C=BA=E5=99=A8=E8=A7=86=E8=A7=89=E7=BB=84=E4=BB=B6=E7=94=9F=E4=BA=A7=E5=
=95=86 =E6=9C=BA=E5=99=A8=E8=A7=86=E8=A7=89=E7=BB=84=E4=BB=B6=E7=94=9F=E4=
=BA=A7=E5=95=86

It seems that the method Zend_Mail::_encodeHeader() is causing the problem.

E-Mail with a Chinese subject is sent correctly, when the following code is used for the method:

protected function _encodeHeader($value)
{
    if (Zend_Mime::isPrintable($value)) {
        return $value;
    } else {
        return '=?' . $this->_charset . '?B?' . base64_encode($value) . '?=';
    }
}

Jacky Chen posted this solution on Fri, 28 Dec 2007 17:21:26 -0800 at:

http://www.mail-archive.com/fw-general@lists.zend.com/msg09005.html

Can his version of Zend_Mail::_encodeHeader() be used to update the official version?

In the meantime, I am subclassing Zend_Mail, overloading Zend_Mail::_encodeHeader() with his version, as I need
to send e-mail with Chinese subjects and also From and To addresses - Zend_Mail::_encodeHeader() is used in
multiple methods.

Thank you for your kind consideration of this change.

Jonathan Maron
Comments
Comment by Tomas Markauskas [ 09/Aug/08 03:05 PM ]
This solution would work only for short headers, because the RFC does not allow the encoded words in the headers
to be longer than 75 characters. The string has to be split to avoid problems with multibyte characters and therefore
has to be split between those characters. I had the same problem and now I have a solution which fixes it for utf-8
string (other charsets later).

I will post a patch in the next few days. It should also close a few other tickets related to Zend_Mail/Zend_Mime.
Comment by Jonathan Maron [ 09/Aug/08 09:58 PM ]
Hello Thomas

Thank you very much for your prompt answer.

I very much look forward to seeing your patch.

Would it be possible for you to send me a copy already?

TIA

Jonathan Maron
Comment by Tomas Markauskas [ 13/Aug/08 01:42 PM ]
Patch for Zend_Mail/Zend_Mime (@10901)

This fixes the described problem (and a few more).
Comment by Tomas Markauskas [ 13/Aug/08 01:51 PM ]
What was the problem:

From http://tools.ietf.org/html/rfc2047#section-2

An encoded-word may not be more than 75 characters long, including
charset, encoding, encoded-text, and delimiters. If it is desirable
to encode more text than will fit in an encoded-word of 75
characters, multiple encoded-words (separated by CRLF SPACE) may be
used.

While there is no limit to the length of a multiple-line header
field, each line of a header field that contains one or more
encoded-words is limited to 76 characters.

From http://tools.ietf.org/html/rfc2047#section-5

The 'encoded-text' in an 'encoded-word' must be self-contained;
'encoded-text' MUST NOT be continued from one 'encoded-word' to
another. This implies that the 'encoded-text' portion of a "B"
'encoded-word' will be a multiple of 4 characters long; for a "Q"
'encoded-word', any "=" character that appears in the 'encoded-text'
portion will be followed by two hexadecimal characters.

Each 'encoded-word' MUST encode an integral number of octets. The
'encoded-text' in each 'encoded-word' must be well-formed according
to the encoding specified; the 'encoded-text' may not be continued in
the next 'encoded-word'. (For example, "=?charset?Q?=?=
=?charset?Q?AB?=" would be illegal, because the two hex digits "AB"
must follow the "=" in the same 'encoded-word'.)

Each 'encoded-word' MUST represent an integral number of characters.
A multi-octet character may not be split across adjacent 'encoded-
word's.

There is still one problem with my patch: the first line of the header will probably exceed the length of 76 characters
because we don't count the length of the header name. Zend_Mime::encodeQuotedPrintableHeader should get the
length of the header name, so it could reduce the length of the first "encoded-word". I haven't seen any cases where
this would cause big problems, so I haven't resolved it.
Comment by Tomas Markauskas [ 16/Aug/08 04:57 AM ]
It would probably fix these two issues too.
Comment by Niko Sams [ 02/Sep/08 01:47 AM ]
Patch worked out fine for me. Thanks.
Comment by Tomas Markauskas [ 02/Sep/08 10:07 AM ]
All these issues seem to be related.
Comment by Tomá? Fejfar [ 11/Sep/08 10:24 AM ]
Someone should fix this, it's critical bug for everyone usin non-ascii charset...
Comment by Tomas Markauskas [ 17/Sep/08 05:53 AM ]
I would like to know if there's any need for other character sets than UTF-8.
Another option to deal with multibyte characters would be to convert all multibyte character sets to UTF-8 in
encodeQuotedPrintableHeader (see attached patch).
[ZF-3876] getMessage() should be getMessages() in
Zend/Mail/Protocol/Smtp.php Created: 06/Aug/08 Updated: 09/Oct/08                       Resolved: 01/Sep/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.6.0RC1
Fix Version/s:          1.6.2

Type:                   Bug                                 Priority:               Major
Reporter:               Sebastian                           Assignee:               Satoru Yoshida
Resolution:             Fixed                               Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Fix Version Priority: Should Have

Description
In lib/Zend/Mail/Protocol/Smtp.php there appears to be a typo: in the helo() function when the client hostname fails to
validate, the exception string fails to be built because the method to get the error messages is incorrect (missing an
"s").




throw new Zend_Mail_Protocol_Exception(join(', ', $this->_validHost-
>getMessage()));

should read

throw new Zend_Mail_Protocol_Exception(join(', ', $this->_validHost-
>getMessages()));


Comments
Comment by Satoru Yoshida [ 01/Sep/08 06:02 PM ]
Solved in SVN r11196.
The getMessage() is not found, but getMessages() function exists in Zend_Validate that was included by
Zend/Mail/Protocol/Abstract.php.

Abstract.php is parent of Smtp.php.
[ZF-3865] Zend_Mail::_encodeHeader() encode incorrect Created: 06/Aug/08
Updated: 06/Oct/08 Resolved: 06/Oct/08
Status:                    Resolved
Project:                   Zend Framework
Component/s:               Zend_Mail
Affects Version/s:         1.5.3
Fix Version/s:             None

Type:                      Bug                                Priority:                Major
Reporter:                  Andrey Shertsinger                 Assignee:                Nico Edtinger
Resolution:                Duplicate                          Votes:                   2
Remaining Estimate: Not Specified
Time Spent:                Not Specified
Original Estimate:         Not Specified

Issue Links:               Duplicate
                           duplicates      ZF-1688    Long header lines containing non-prin...         Resolved
                           Related
                           is related to   ZF-3912    Incorrect encoding of 'subject' in Ch...         Resolved

Description
correct subject header :

Subject: =?utf-
8?Q?=D0=A0=D0=B5=D0=B3=D0=B8=D1=81=D1=82=D1=80=D0=B0=D1=86=D0=B8=D1=8F=20=D0=BD?=
=?utf-8?Q?=D0=B0=20=D0=BF=D0=BE=D1=80=D1=82=D0=B0=D0=BB=D0=B5?=

but Zend_Mail::_encodeHeader() do this (by one line);

Subject: =?utf-8?Q?=D0=A0=D0=B5=D0=B3=D0=B8=D1=81=D1=82=D1=80=D0=B0=D1=86=D0=B8=D1=8F
=D0=BD= =D0=B0 =D0=BF=D0=BE=D1=80=D1=82=D0=B0=D0=BB=D0=B5?=

to resolve issue (Zend/Mail.php) in _encodeHeader() just add line:
$quotedValue = join("?=\n =?" . $this->_charset . '?Q?', split("=\n",$quotedValue));

after :
$quotedValue = str_replace(array('?', ' '), array('=3F', '=20'), $quotedValue);
[ZF-3716] Show boundary without content type Created: 22/Jul/08                             Updated: 12/Sep/08
Resolved: 12/Sep/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       None
Fix Version/s:           None

Type:                    Improvement                      Priority:              Trivial
Reporter:                Thomas Schaaf                    Assignee:              Nico Edtinger
Resolution:              Not an Issue                     Votes:                 0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
'content-type' => string 'multipart/mixed; boundary="----=_NextPart_000_006C_01C8E533.F00DFB00"'

Its really anoying to have to filter out the boundary..




Comments
Comment by Thomas Schaaf [ 31/Jul/08 10:57 AM ]
I have found a way to read out the boundary very easily:
$boundary = Zend_Mime_Decode::SplitContentType($value['header']['content-type'], 'boundary');
Comment by Nico Edtinger [ 12/Sep/08 01:04 PM ]
It's even easier if you use Zend_Mail_Message: $message->getHeaderField('content-type', 'boundary'); // also works
Zend_Mail_Part
[ZF-3689] Recycle a Zend_Mail object and allow setting a new from Created:
19/Jul/08 Updated: 03/Jan/09 Resolved: 03/Jan/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.5.2, 1.7.2
Fix Version/s:          1.7.3

Type:                   Improvement                          Priority:                Major
Reporter:               Till Klampaeckel                     Assignee:                Satoru Yoshida
Resolution:             Fixed                                Votes:                   3
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Dependency
                        depends on       ZF-1626      Add methods for removing or replacing...               Resolved
Fix Version Priority: Nice to Have

Description
/**
      * Sets From-header and sender of the message
      *
      * @param string     $email
      * @param string     $name
      * @return Zend_Mail Provides fluent interface
      * @throws Zend_Mail_Exception if called subsequent times
      */
    public function setFrom($email, $name = '')
    {
         if ($this->_from === null) {
             $email = strtr($email,"\r\n\t",'???');
             $this->_from = $email;
             $this->_storeHeader('From', $this->_encodeHeader('"'.$name.'"').'
<'.$email.'>', true);
         } else {
             /**
              * @see Zend_Mail_Exception
              */
             require_once 'Zend/Mail/Exception.php';
             throw new Zend_Mail_Exception('From Header set twice');
         }
         return $this;
    }

Currently it will always throw an exception. I don't see why I cannot set another from if I am try to send out multiple
emails in a single run but with different froms.




Comments
Comment by Till Klampaeckel [ 20/Jul/08 11:41 PM ]
I managed to get around this issue by extending Zend_Mail, added my own methods for setFrom() and setSubject. In
setFrom, you have to make sure to also unset $this->_headers['From'], otherwise your email ends up with two From
headers, which also works, but some MUAs screw up.

It would be nice if this made it into Zend_Mail though, I can provide patches if wanted.
Comment by Satoru Yoshida [ 03/Jan/09 04:01 AM ]
I think it depends on
Comment by Satoru Yoshida [ 03/Jan/09 04:29 AM ]
I think clearFrom() function will solve your problem.

I add the function at SVN r13499 .
[ZF-3664] No init() function called in constructor Created: 17/Jul/08                           Updated: 08/Nov/08
Resolved: 08/Nov/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.5.2
Fix Version/s:           None

Type:                    Bug                                   Priority:           Minor
Reporter:                Christopher M. Black                  Assignee:           Nico Edtinger
Resolution:              Not an Issue                          Votes:              0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
When extending Zend_Mail I discovered that the Zend_Mail class does not follow the convention to call an init()
method as the last constructor action. To override settings when the class is instantiated one must override the
constructor itself.




Comments
Comment by Benjamin Eberlei [ 08/Nov/08 12:32 AM ]
There is no convention to call init() as last constructor action.

I vote for No-Issue.
Comment by Dolf Schimmel (Freeaqingme) [ 08/Nov/08 05:51 AM ]
There's no convention for ZF that prescribes the need of an init-method. If you feel there should be one in Zend_Mail,
you could add a feature request for this.
[ZF-3646] Automaticly add attachments for included images Created: 14/Jul/08
Updated: 30/Jan/09 Resolved: 30/Jan/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      None
Fix Version/s:          None

Type:                   New Feature                            Priority:                  Minor
Reporter:               Michal Vrchota                         Assignee:                  Benjamin Eberlei
Resolution:             Won't Fix                              Votes:                     0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:          example.php           Part.php
Issue Links:            Dependency
                        depends on       ZF-3645      Zend_Mime_Part missing Content-Locati...               Resolved

Description
Most common email clients do not show embeded images, unless the user allow that
Therefore there should be some functionality which automaticly send embeded images as email attachments with
correct headers.
I believe this is worth to implement.

Programmer just passes $mail->setBodyHTML() and something like $mail->sendEmbededImagesAsAttachment()
and all <img src=xxx> will be automaticly included in email as attachments with correct headers

working example with source code inside attachment




Comments
Comment by Michal Vrchota [ 14/Jul/08 04:37 PM ]
Zend_Mime_Part with content-location header ability
Comment by Michal Vrchota [ 14/Jul/08 04:38 PM ]
Example how to automaticly load attachments for embeded images in email
Comment by Michal Vrchota [ 14/Jul/08 04:38 PM ]
This feature requires Content-Location header
Comment by Nico Edtinger [ 07/Nov/08 05:14 PM ]
That sounds like too much magic for Zend_Mail. It's already possible to parse the html body and fetching the mails
before creating the mail message. And normally you'd use the content-id with a cid: URL. If we leave that out of
Zend_Mail you also have to possibility to use data: URIs, or inline stylesheets or javascript - adding all this
possibilities to Zend_Mail makes it just bloated.
Comment by Benjamin Eberlei [ 16/Jan/09 09:43 AM ]
This is an extension that should reside in userland code, not in Zend_Mail itself.
Comment by Michal Vrchota [ 16/Jan/09 11:20 AM ]

You have conviced me        I agree this feature will really bloat the code little bit.
Comment by Benjamin Eberlei [ 16/Jan/09 11:29 AM ]
issue is only resolved not closed.
[ZF-3641] Zend_Mail: Wrong MIME header encoding Created: 14/Jul/08                                         Updated:
06/Oct/08 Resolved: 06/Oct/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       None
Fix Version/s:           None

Type:                    Bug                                  Priority:                Major
Reporter:                Tobias Gies                          Assignee:                Nico Edtinger
Resolution:              Duplicate                            Votes:                   3
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Issue Links:             Duplicate
                         duplicates       ZF-1688      Long header lines containing non-prin...               Resolved
                         Related
                         is related to    ZF-3912      Incorrect encoding of 'subject' in Ch...               Resolved

Description
(Posted for Tomas Markauskas on the fw-formats mailing list. The following text is copied from his mail.)

I noticed that subject headers in some emails sent with Zend_Mail aren't shown correctly in Gmail. I think the
implementation of RFC
1522 in Zend_Mail::_encodeHeader() is not correct. The RFC 1522 says (http://tools.ietf.org/html/rfc1522#section-2
), that if the string is too long to fit into 75 characters, it can be written as multiple encoded-words (and not encoded-
texts), like this:

Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
=?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=

(Thats from RFC 1522 Section 8: http://tools.ietf.org/html/rfc1522#section-8 )

But Zend_Mail uses just the simple Quoted-Printable encoding, which is used in bodies etc. I still don't have any
rigths to submit issues in Jira, so I created a page with a simple fix for Zend_Mail/Zend_Mime:

http://code.tamole.net/zend_mail/

My two classes:

http://code.tamole.net/zend_mail/Fix_Mail.phps
http://code.tamole.net/zend_mail/Fix_Mime.phps

You can see the Zend_Mail result with an example string and the result of my fixed implementation on the page.

As you can also see, the current implementation has problems with strings, containing lots of spaces or question
marks, ie. not every line is within required 75 characters. That's fixed there too now.
[ZF-3625] Incorrect Content-Type encode headers Created: 11/Jul/08                            Updated: 07/Nov/08
Resolved: 07/Nov/08
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     None
Fix Version/s:         None

Type:                  Bug                              Priority:             Major
Reporter:              Oleg                             Assignee:             Nico Edtinger
Resolution:            Not an Issue                     Votes:                0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified


Description
When mbstring enabeled

<?php
require_once 'Zend/Mail.php';
require_once 'Zend/Mail/Transport/Sendmail.php';

$tr = new Zend_Mail_Transport_Sendmail('-freturn_to_me@example.com');
Zend_Mail::setDefaultTransport($tr);

$mail = new Zend_Mail();
$mail->setBodyText('This is the text of the mail.');
$mail->setFrom('somebody@example.com', 'Some Sender');
$mail->addTo('somebody_else@example.com', 'Some Recipient');
$mail->setSubject('TestSubject');
$mail->send();

?>
E_WARNING: "mb_send_mail() [function.mb-send-mail]: Unsupported charset ""iso-8859-1"" - will be regarded as
ascii"
at /home/..../ZendFramework/Zend/Mail/Transport/Sendmail.php line 91

php.ini:

extension=php_mbstring.dll
[mbstring]
mbstring.language = Russian
mbstring.internal_encoding = UTF-8
mbstring.func_overload = 1




Comments
Comment by Satoru Yoshida [ 01/Sep/08 06:46 PM ]

Privet, Oleg.
Do you try with 'mb_language = Russian' in php.ini ?

In japanese, we need 'mb_language = Japanese'.
Comment by Oleg [ 01/Sep/08 10:25 PM ]
It was a php bug http://bugs.php.net/bug.php?id=45486
Comment by Lukas Smith [ 07/Oct/08 01:16 AM ]
So this means this bug can be closed?
[ZF-3591] Zend_Mail_Message - no subject-decoding reading eml-file
Created: 07/Jul/08 Updated: 07/Nov/08 Resolved: 07/Nov/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.5.2
Fix Version/s:          None

Type:                   Bug                                 Priority:                Minor
Reporter:               Tobias Olry                         Assignee:                Nico Edtinger
Resolution:             Not an Issue                        Votes:                   1
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
When reading an email message from file (imap, eml, ...) the subject's q-encoding isn't decoded at all.

File is read using

new Zend_Mail_Message(array('file'=>$filePath));

The File to be read must have an q-encoded subject such as

Subject: =?iso-8859-15?Q?lee=E4r=20=A4?=



Comments
Comment by Alexandre Lemaire [ 30/Jul/08 08:25 PM ]
I have a similar issue to report, where subjects are not being properly decoded. Here's a message header that
reproduces the issue:

Message-ID: <488E0442.9040303@xxx.xxx>
Date: Mon, 28 Jul 2008 20:39:14 +0300
From: Support <yyy@yyy.yy>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: TestBox <yyy@yyy.yyy>
Subject: Re: =?UTF-8?B?dGVzdC/Qv9GA0L7QstC10YDQutCw?=
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


Здравейте,
тест
Comment by Nico Edtinger [ 07/Nov/08 05:02 PM ]
That's because you've set iconv to an encoding that can't represent the characters (euro sign in the first example,
russian chars in the second one). Zend_Mime_Decode doesn't touch your iconv settings. If you set
iconv.internal_encoding to UTF-8 in you php.ini or via ini_set() you'll get the decoded header. Of course the rest of
the code needs to be able to handle that encoding.
[ZF-3588] Incorrect encoding of unicode subjects Created: 06/Jul/08                                       Updated: 04/May/09
Resolved: 06/Oct/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.5.2
Fix Version/s:           None

Type:                    Bug                                    Priority:                Major
Reporter:                Eran Galperin                          Assignee:                Nico Edtinger
Resolution:              Duplicate                              Votes:                   4
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Issue Links:             Duplicate
                         duplicates        ZF-1688      Long header lines containing non-prin...                 Resolved
                         Related
                         is related to     ZF-3912      Incorrect encoding of 'subject' in Ch...                 Resolved

Description
When using Zend_Mail with utf-8 encoding and hebrew characters, the subject is incorrectly encoded causing
artifacts to appear. I've tracked this to the protected method _encodeHeader(), line 393 in Zend_Mail:

protected function _encodeHeader($value)
    {
      if (Zend_Mime::isPrintable($value)) {
          return $value;
      } else {
          $quotedValue = Zend_Mime::encodeQuotedPrintable($value);
          $quotedValue = str_replace(array('?', ' '), array('=3F', '=20'),
$quotedValue);
          return '=?' . $this->_charset . '?Q?' . $quotedValue . '?=';
      }
    }

Replacing the quoting method to encodeBase64() of Zend_Mime seems to fix the issue. Meaning:

protected function _encodeHeader($value)
    {
      if (Zend_Mime::isPrintable($value)) {
          return $value;
      } else {
            return '=?' . $this->_charset . '?B?' .
Zend_Mime::encodeBase64($value) . '?=';
      }
    }

Will return a correctly formatted utf-8 subject. I'm not an expert on Mime so I can't tell if this is the best solution.
However it should be fixed to correctly format utf-8 subjects
Comments
Comment by Sébastien Gallet [ 01/Aug/08 12:42 AM ]
That issue is also present in 1.5.3 and 1.6.0 rc1.

Here is another fix without using the base64 encoding.
It's not perfect either but it corrects the issue.

protected function _encodeHeader($value)
    {
      if (Zend_Mime::isPrintable($value)) {
          return $value;
      } else {
          $quotedValue = Zend_Mime::encodeQuotedPrintable($value);
          $quotedValue = str_replace(array('?', ' ', '_', '=' .
Zend_Mime::LINEEND),
               array('=3F', '=20', '=5F', ''), $quotedValue);
          return '=?' . $this->_charset . '?Q?' . $quotedValue . '?=';
      }
    }
Comment by Levan Cheishvili [ 04/May/09 05:28 AM ]
It is still not working with some hebrew letters / or combinations of letters in ZF 1.7.1.
I am using Zend_Mail from ZF 1.7.1. I had to apply the above given patch, and now it is working.
When are you going to update ZF with this patch?
[ZF-3509] Only adding BCC addresses fails with Missing To header when
using Zend_Mail Created: 25/Jun/08 Updated: 25/Oct/10 Resolved: 07/Nov/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.5.2
Fix Version/s:           None

Type:                    Bug                                   Priority:             Major
Reporter:                Jacob Kiers                           Assignee:             Nico Edtinger
Resolution:              Not an Issue                          Votes:                1
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Issue Links:             Duplicate
                         is duplicated by     ZF-10319     "Missing To header" should never been...     Resolved

Description
I just tried to add BCC addresses (and only them) to an instance of Zend_Mail, I end up with a Missing To header
Exception:
The code:
$this->_mail = new Zend_Mail();
foreach ($recipient_sql->fetchAll() as $recipient) {
$this->_mail->addBcc($recipient['email']);
}

I end up with this:
An error occured in an observer: Missing To header

Stack trace: #0 /usr/share/php/Zend/Mail/Transport/Abstract.php(337): Zend_Mail_Transport_Sendmail-
>_prepareHeaders(Array)
#1 /usr/share/php/Zend/Mail.php(720): Zend_Mail_Transport_Abstract->send(Object(Zend_Mail))
#2 /usr/local/acos/watchdog/Annabel/Watchdog/Observer/Mail.php(82): Zend_Mail->send()
#3 /usr/local/acos/watchdog/Annabel/Watchdog/Watcher/Abstract.php(338): Annabel_Watchdog_Observer_Mail-
>update()
#4 /usr/local/acos/watchdog/Annabel/Watchdog/Watcher/File.php(67): Annabel_Watchdog_Watcher_Abstract-
>notifyObservers()
#5 /usr/local/acos/watchdog/Annabel/Watchdog.php(96): Annabel_Watchdog_Watcher_File->watch()
#6 /usr/local/acos/watchdog/watchdog/watchdog_run.php(74): Annabel_Watchdog->run()
#7 {main}

ZF version 1.5.2, I don't know if it also affects other versions.

Uname -a output in case that's important:
PHP 5.2.0-8+etch11 (cli) (built: May 10 2008 10:46:24)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans




Comments
Comment by Nico Edtinger [ 07/Nov/08 04:30 PM ]
That's because Zend_Mail_Transport_Sendmail uses mail(), which needs a To for the first parameter. Use a dummy
address or Zend_Mail_Transport_Smtp instead.
[ZF-3488] Missing closing bracket in "Example 25.9. Changing the MIME
Boundary" Created: 20/Jun/08 Updated: 02/Sep/08 Resolved: 02/Jul/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.5.2
Fix Version/s:          1.6.0

Type:                   Docs: Problem                   Priority:              Major
Reporter:               Shahar Evron                    Assignee:              Satoru Yoshida
Resolution:             Fixed                           Votes:                 0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Language:               English

Description
The code sample at the on-line docs for 1.5.2 on "Example 25.9. Changing the MIME Boundary" is broken:

$mail->setMimeBoundary('=_' . md5(microtime(1) . $someId++);

Should be:

$mail->setMimeBoundary('=_' . md5(microtime(1) . $someId++));


Comments
Comment by Satoru Yoshida [ 02/Jul/08 08:33 AM ]
Solved in SVN r9879
Comment by Wil Sinclair [ 02/Sep/08 10:39 AM ]
Updating for the 1.6.0 release.
[ZF-3487] Zend_Mail_Protocol_Smtp: Incorect rfc implementation Created:
20/Jun/08 Updated: 12/Sep/08 Resolved: 12/Sep/08
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     1.5.2
Fix Version/s:         None

Type:                  Bug                                Priority:              Minor
Reporter:              Martin Milesich                    Assignee:              Nico Edtinger
Resolution:            Not an Issue                       Votes:                 0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified


Description
At now you cannot call helo function more than one in one session. If you do you get an 'Cannot issue HELO to
existing session' exception.

But in RFC 2821 4.1.1 is writen:

The MAIL command (or the obsolete SEND, SOML, or SAML commands) begins a mail transaction. Once started, a
mail transaction consists of a transaction beginning command, one or more RCPT commands, and a DATA
command, in that order. A mail transaction may be aborted by the RSET (or a new EHLO) command.




Comments
Comment by Nico Edtinger [ 12/Sep/08 12:40 PM ]
Normally you'd use Zend_Mail_Transport_Smtp, which does send an RSET in _sendMail() if the connection has been
used before. If want to use the protocol class directly call rset() to reset the connection before sending an other
HELO.
[ZF-3479] Zend_Mail_Protocol_Pop3: Wrong parsing of termination octet
in multiline responses Created: 18/Jun/08 Updated: 21/May/09 Resolved: 24/Feb/09
Status:                    Closed
Project:                   Zend Framework
Component/s:               Zend_Mail
Affects Version/s:         1.5.2
Fix Version/s:             None

Type:                      Bug                               Priority:               Blocker
Reporter:                  Thorsten Suckow-Homberg           Assignee:               Nico Edtinger
Resolution:                Incomplete                        Votes:                  0
Remaining Estimate: Not Specified
Time Spent:                Not Specified
Original Estimate:         Not Specified


Description
What steps will reproduce the problem?
Fetch a message from a POP3 server where the email-body contains a single line with a dot ("."). For example (sent
by the groups.google.com-Google Maps API):
<quote>
Looking for example - Can this be done? - 2 new
-----------------------------------------------
I have a google map on a web page. I would like for the user to enter in a=
=20
state and hit submit. Using AJAX, I want to be able to access a database on=
=20
the server, select all the addresses in that state and return them so they c=
an
be displayed on the Google map. I was wondering if I have to do this using a=
.
NET user control since I - Mon, Jun 16 2008 1:14 pm=20
2 messages , 2 authors
http://groups.google.com/group/Google-Maps-API/t/928e1d733e1a5c85?hl=3Den
</quote>

What is the expected output?
The class will read the message from the server until the termination octet (wrapped in CRLF: "\r\n.\r\n") occurs.

What do you see instead?
The class will read the message and return only the contents until the single line with the dot "." appears. Apparently,
it is not parsing the termination octet as returned by the server correctly and assumes that any line in a message
containing only a dot "." represents a termination octet.

Can you provide a fix for this problem?
In line 188 in Zend/mail/Protocol/Pop3.php, replace

[code]
while ($line && trim($line) != '.') {
[/code]

with

[code]
while ($line && $line != ".\r\n") {
[/code]




Comments
Comment by Nico Edtinger [ 15/Sep/08 03:17 AM ]
After rereading the RFC, the proposed patch is not correct or won't fix the problem. The trim should only remove \r
and \n, but it's used to avoid problems with non-conforming servers (like ones that terminate lines with only \n).

Now the problem is, that a valid message with a single dot in a line would still have ".\r\n" and that's the same as the
line with the termination octet. The server should send "..\r\n" (and Zend_Mail_Protocol_Pop3 should remove the first
dot), but it seems like your POP3 server isn't careful enough.
Comment by Nico Edtinger [ 21/Sep/08 11:35 AM ]
The termination octet is now handled correctly ("..\r\n" becomes ".\r\n" in the message body).

The question remains, which wrong RFC violation we should support in addition. IMO wrong newlines are more
common and therefor supporting "\n" or and other combination of "\r" and "\n" more important, than a server, that
does not escape a line with a single dot correctly. I leave this task open for comments.
Comment by Thorsten Suckow-Homberg [ 10/Oct/08 04:19 AM ]
Nico, did you change the code in ZF 1.6.*? Because a diff to 1.5.2 does not give me any changes...
Comment by David Goodwin [ 04/Nov/08 01:59 AM ]
Hi,

This bug still exists in the 1.6 branch (revision 12162).

In my instance, the subject line wraps and has a single '.' on the end - which after the trim gets interpreted as part of
the POP3 protocol.

i.e. This is what I see when I telnet into the cyrus pop3 server and fetch the problem message :

RETR 1
+OK Message follows
Return-Path: <postmaster@xxxxxxxx.co.uk>
Received: from xxxxx.xxxxxxxx.com ([unix socket])
by xxxxx.xxxxx.com (Cyrus v2.3.7-Invoca-RPM-2.3.7-2.el5) with LMTPA;
Tue, 04 Nov 2008 05:27:46 +0000
X-Sieve: CMU Sieve 2.3
Received: from xxxxx.xxxxx.com (xxxxxx.xxxxxxx.com [xx.xx.xx.xx])
by xxxxx.xxxxxxxx.com (Postfix) with ESMTP id 7474029D92
for <return@xxxx.xxx>; Tue, 4 Nov 2008 05:27:46 +0000 (GMT)
Received: from surfcontrol.xxxxxx.local (xx.xxx.xxx.xx) by xxxx.xxxx.xxx (PowerMTA(TM) v3.5r9) id h1vel40mav0j for
<return@xxxx.com>; Tue, 4 Nov 2008 05:27:46 +0000 (envelope-from <postmaster@xxxxxxxxxxx.xx>)
Date: Tue, 04 Nov 2008 05:29:16 +0000
From: <postmaster@xxxxxx.co.uk>
To: <return@xxxx.com>
Subject: AutoNotify: Payday loans on call 24 hours a day. Between 80 and 750
.
Content-Type: multipart/mixed;
boundary="----=_NextPart_SEF_2008_11_04_05_29_16_28319"
X-SEF-Processed: 6_0_1_111__2008_11_04_05_29_16
Message-Id: <20081104052746.7474029D92@xxxxx.xxxxxxxxx.com>

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

Message [oa129842ee9f84d02a5adecdb6bfb5ed6.pro] triggered rule [Anti-Spam A=
gent (1)] at 05:29:16 04/11/2008=0D=0A=0D=0ASender: return@xxxx.com=0D=0ARe=
cipient(s): barrie@xxxxxxx.co.uk=0D=0ASubject: Payday loans on call 24 hou=
rs a day. Between 80 and 750.
------
.
DELE 1
+OK message deleted
quit

Note, the single full stop/period which is on the line AFTER the subject: - and it is indented correctly.

When trying to parse the above, the class fails with an unhelpful message of 'cannot retrieve message' - and ends up
thinking 'Content-Type: multipart/mixed;' is the response to the previous command.....
Comment by David Goodwin [ 04/Nov/08 02:01 AM ]
hmm, well the original message is indented correctly; clearly posting here gets mangled.

{{
To: <return@xxxxx.com>
Subject: AutoNotify: Payday loans on call 24 hours a day. Between 80 and 750
.
Content-Type: multipart/mixed;
}}

(final attempt to get it rendering properly)
Comment by Nico Edtinger [ 07/Nov/08 01:02 PM ]
Thorsten: yes it was fixed in trunk

David: That's a server problem. I've this message in my INBOX file:

         From next-message@example.com Mon Jan 00 00:00:00 0000
         To: to@example.com
         Subject: Dot Test
         .
         Date: Sun, 01 Jan 2000 01:00:00 +0000
         From: from@example.com
         X-UID: 7
         Status: RO

         Before the dot
         .
         is after the dot

With dovecot I get:

         RETR 7
         +OK 139 octets
         To: to@example.com
         Subject: Dot Test
         ..
         Date: Sun, 01 Jan 2000 01:00:00 +0000
         From: from@example.com

         Before the dot
         ..
         is after the dot
         .

Maybe you could post your message source with all chars printed, including \r and \n - at least the snippet from your
last comment.
Comment by Nico Edtinger [ 24/Feb/09 02:46 AM ]
no response
Comment by Landon Bradshaw [ 21/May/09 03:00 PM ]
We were using qmail and ran into the same problem ... but I can verify with version 1.8.1 it is working properly
[ZF-3478] require_once and case sensitive Created: 18/Jun/08                                  Updated: 12/Sep/08 Resolved:
12/Sep/08
Status:                    Resolved
Project:                   Zend Framework
Component/s:               Zend_Mail
Affects Version/s:         1.5.0
Fix Version/s:             None

Type:                      Bug                                  Priority:                Major
Reporter:                  Full Name                            Assignee:                Nico Edtinger
Resolution:                Cannot Reproduce                     Votes:                   0
Remaining Estimate: Not Specified
Time Spent:                Not Specified
Original Estimate:         Not Specified


Description
I installed the version 1.5.0 on a localhost on my computer and I've developed an application. All was working on a
local computer. But when I putted the version on line, I had a php error message.

It seems that some server are case sensitive and in the 1.5.0 version some classes are called with "require_once",
like this:

           require_once 'Zend/mail/.../...';

instead of

           require_once 'Zend/Mail/.../...';

I only checked it in the Mail module. I don't know what about the other require_once calls in the other modules...


Hope it's gona be helpfull




Comments
Comment by Nico Edtinger [ 18/Jun/08 09:56 AM ]
Do you know which files you found 'require_once 'Zend/mail/.../...';'? With a quick grep I couldn't find /mail/ anywhere,
but in the docs. Also you should upgrade to the latest version.
Comment by Full Name [ 18/Jun/08 12:03 PM ]
I corrected the mistake with a grep to, but I haven't any record of the olds files... sorry.
All the corrupted lines where in the Mail.php file and in the Mail folder. That's all I can tell you.
Maybe I had an old version. I'll check in the new one.
thx!
[ZF-3377] clear Recipients function Created: 03/Jun/08                         Updated: 03/Jan/09 Resolved: 03/Jan/09
Status:                   Resolved
Project:                  Zend Framework
Component/s:              Zend_Mail
Affects Version/s:        1.7.2
Fix Version/s:            1.7.3

Type:                     Improvement                           Priority:             Major
Reporter:                 Gunter Spöcker                        Assignee:             Satoru Yoshida
Resolution:               Duplicate                             Votes:                2
Remaining Estimate: Not Specified
Time Spent:               Not Specified
Original Estimate:        Not Specified

Issue Links:              Duplicate
                          duplicates      ZF-1626      Add methods for removing or replacing...             Resolved
Fix Version Priority: Should Have

Description
I would suggest to add a function "clearRecipients()" to Zend_Mail. It allows one to send personalised mails to more
than one recipient without creating a new mail object each time:

public function clearRecipients() {
$this->_to = array();
$this->_recipients = array();

unset($this->_headers['To']);
unset($this->_headers['Cc']);
unset($this->_headers['Bcc']);
}

So it's possible to do something like this:

          create mail object, set subject and so on
          add recipient
          set mail text to something like "Dear Mr Miller, ..."
          send mail
          clear recipients
          add new recipient
          set mail text to something like "Dear Mrs Miller, ..."
          send mail
           ...




Comments
Comment by Nico Edtinger [ 18/Jun/08 10:08 AM ]
I'm not sure how useful this is. What you want to do can be solved by just creating a new Zend_Mail object. The only
property you don't change (or maybe you just didn't mention it) is the subject. As long as you reuse the transport (if
you're using SMTP) sending multiple mails is not a problem. But maybe I'm just missing something?!
Comment by Gunter Spöcker [ 18/Jun/08 10:23 AM ]
A more important example would be attachments. Imagine you have attached some images and other files to one
mail object, it's not a very good idea to load all this data for every single mail, just because you want to change the
recipient.
Comment by Tomas Korcak [ 10/Jul/08 05:42 AM ]
Totally agree with Gunter. It is the basic functionallity. Why would i have to create new object while i can reuse some.
Please consider that. I need fx. clearRecipients(), clearSubject().
Comment by Satoru Yoshida [ 03/Jan/09 03:58 AM ]
I think it duplicates
[ZF-3362] about BCC and TO in Zend_Mail_Transport_Sendmail Created:
01/Jun/08 Updated: 14/Dec/09 Resolved: 18/Sep/09
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.5.2
Fix Version/s:           1.10.0

Type:                    Docs: Problem                       Priority:            Minor
Reporter:                Bart McLeod                         Assignee:            Benjamin Eberlei
Resolution:              Fixed                               Votes:               0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

File Attachments:           patch_ZF3362.diff
Fix Version Priority: Nice to Have

Description
$mail->addTo('me@example.com');
$mail->addBcc('him@example.com');
$mail->addBcc('them@example.com');

The above code snippet adds all three mail addresses to the TO field. $mail is an instance of Zend_Mail. I would
expect the latter two to be added to BCC field.

I am using standard/trunk from svn at the time 1.5.2 is released.

NOTE:
Applies to using IIS under VISTA with no explicit mail transport set.




Comments
Comment by Wil Sinclair [ 01/Jun/08 12:33 PM ]
Please evaluate and categorize as necessary.
Comment by Karl Mikkelsen [ 11/Jun/08 09:42 PM ]
To fix this problem

File: Zend/Mail.php

500 /**
501 * Return list of recipient email addresses
502 *
503 * @return array (of strings)
504 */
505 public function getRecipients()
506 { 507 return $this->_to; 508// return array_keys($this->_recipients); 509 }

This returns all recipients by default
comment out line 508 and replace with line 507 to only return those added in the two!!!

CC and BCC will still work as they are added to the headers which are still included.
Comment by Karl Mikkelsen [ 11/Jun/08 09:57 PM ]
Further Investigation found this is only happening on a windows machine IIS not on apache on linux
Comment by Bart McLeod [ 12/Jun/08 01:57 AM ]
I must add that in my case it happens on windows Vista BU using Apache and remote smtp server of ISP.
Comment by Karl Mikkelsen [ 12/Jun/08 05:03 PM ]
              
                          o
                                 
                                      Ignore the last change as it ill muck up the function to find out what recipients are
                                       getting mail ****

Yeah you would be right Bart - This would happen on all Windows machines as it has to do with the way the built-in
mail(); function works.

On windows it acts as a kind of smtp router - on linux it is a direct hook into the sendmail MTA.

So there is a fundamental difference in the two and hence why the bug only turns up on a windows installation.

The following fix only puts the "To" recipients to the $to; in mail(); and all the Bcc and Cc are still added to the
headers to they still get the email!!!!!

Change file....

File: Zend/Mail/Transport/Abstract.php

// Determine recipients, and prepare headers
REMOVE THIS LINE
// $this->recipients = implode(',', $mail->getRecipients()); /** This is the old code which gets all recipients and adds
them to the "to" in mail() - this is not good */

ADD THIS LINE
$this->recipients = implode(',', $mail->getTo()); // now you only get the _to recipients to add to the to in mail()

$this->_prepareHeaders($this->_getHeaders($boundary)); //All Bcc and Cc are still added as they are added in the
headers where they belong

Add this function to...

File: Zend/Mail.php

/**

         Return list of "To" recipient email addresses only, this ignore's the Cc and Bcc
      
         @return array (of strings)
          */
          public function getTo()
          {
          return $this->_to;
         }

This is a better fix!!!!!!!! - Same basic idea though
Comment by Nico Edtinger [ 18/Jun/08 10:59 AM ]
Am I right, that this only happens with the sendmail transport? mail() has a different behavior under Windows. Have
you tried using Zend_Mail_Transport_Smtp? Does it have similar problems?

I currently don't have a Windows with PHP here, so if anyone is faster than me providing a patch ... But recipients and
the to header are two different things. The recipients are used for the envelope and if you replace it with what's in the
to header you might break the SMTP transport. There is already special treatment for Windows in
Zend_Mail_Transport_Sendmail::_prepareHeaders() and if there's something that should be fixed it's in this method.
Comment by Bart McLeod [ 18/Jun/08 12:41 PM ]
I must admit that I did not look into transport at all. I have seen it come by when reading about Zend_Mail, but I
thought, well, if it wraps mail(), it will work, since mail() works. This basically means that I did not set the transport
explicitly, so I am using the default behavior under windows.

To me personally it doesn't really matter if it gets fixed fast, my production server being linux.

I tried the transport just now, to be sure if it makes a difference, and yes, it does, under windows using new
Zend_Mail_Transport_Smtp('smtp.myserver.nl') works as it should!

So I guess it may come down to choosing the right transport for the job. The only downside I can see is that I will now
have to configure the smtp server for the live host and the local testserver. But that's no big deal.
Comment by Bart McLeod [ 18/Jun/08 12:43 PM ]
Changed priority to minor, because it works under windows if you use Zend_Mail_Transport_Smtp.
Comment by Satoru Yoshida [ 03/Jan/09 05:30 PM ]
Change summary to be more understandable easyly
Comment by Bart McLeod [ 04/Jan/09 01:31 AM ]
Changed summary.
Comment by Benjamin Eberlei [ 18/Sep/09 04:52 AM ]
I'll close this as documentation related issue, since this is also stated in the PHP manual and stuff.

A passage will be added to the documentation and i'll close, any comments?
Comment by Benjamin Eberlei [ 18/Sep/09 11:21 AM ]
Fixed as documentation issue
Comment by Bart McLeod [ 24/Sep/09 01:52 AM ]
Well done.
[ZF-3147] Unit test failures on Linux when run as root Created: 18/Apr/08                                      Updated:
02/Sep/08 Resolved: 22/Apr/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.6.0RC2
Fix Version/s:           1.6.0

Type:                    Unit Tests: Problem                  Priority:                Major
Reporter:                Darby Felton                         Assignee:                Nico Edtinger
Resolution:              Fixed                                Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Issue Links:             Dependency
Fix Version Priority: Should Have

Description
Results from PHP 5.2.5 on Linux (run as root):

2) testSleepWakeRemoved(Zend_Mail_MboxTest)
no exception while waking with non readable file

3) testNotReadableFolder(Zend_Mail_MboxFolderTest)
no exception while loading invalid dir with subfolder not readable


Comments
Comment by Wil Sinclair [ 18/Apr/08 03:48 PM ]
Please evaluate and categorize/assign as necessary.
Comment by Nico Edtinger [ 22/Apr/08 10:49 AM ]
I don't know if the tests should run as root, but there might be a situation where you have to.

The problem is the code checks after an unserialize if the file can still be read and as root can always read everything
we can't test the error handling.

I thought of the three possibilities, two of them are dropping privileges and forking and dropping. Both are things that
should be solved in the TestHelper if we want everything to work as root. Now the test is just marked as skipped if it
fails and you're root.

Of course the test could still fail if you have a different superuser with an userid != 0. But that might not be the best
user to test as your webserver or mail scripts shouldn't run as that user.
Comment by Wil Sinclair [ 02/Sep/08 10:39 AM ]
Updating for the 1.6.0 release.
[ZF-3095] Zend_Mail_Protocol_Imap::listMailbox - Invalid argument
supplied for foreach() Created: 10/Apr/08 Updated: 02/Sep/08 Resolved: 22/Apr/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.5.1
Fix Version/s:          1.6.0

Type:                   Bug                               Priority:              Major
Reporter:               Cole Snodgrass                    Assignee:              Nico Edtinger
Resolution:             Fixed                             Votes:                 0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
Appears that calling Zend_Mail_Storage_Imap::getFolders with an invalid parameter will cause a PHP warning to
be thrown as Zend_Mail_Protocol_Imap will attempt to iterate over a boolean value.

reproduce
$mail = new Zend_Mail_Storage_Imap(array(..., 'ssl' => 'SSL'));
$folders = $mail->getFolders('DoesNotExist');

this will eventually end up calling the following code

Zend_Mail_Protocol_Imap::list
public function listMailbox($reference = '', $mailbox = '*')
    {
        $result = array();
        $list = $this->requestAndResponse('LIST', $this-
>escapeString($reference, $mailbox));
        if (!$list) {
            return $result;
        }

        foreach ($list as $item) {
            if (count($item) != 4 || $item[0] != 'LIST') {
                continue;
            }
            $result[$item[3]] = array('delim' => $item[2], 'flags' =>
$item[1]);
        }

            return $result;
      }

Which will cause a PHP Warning when it tries to loop through $list as $list is a bool(true) and not an array.




Comments
Comment by Wil Sinclair [ 18/Apr/08 03:48 PM ]
Please evaluate and categorize/assign as necessary.
Comment by Nico Edtinger [ 22/Apr/08 12:05 PM ]
Good catch. It seems a bit strange, that you don't get an error with an invalid reference, but it's now checked.
Comment by Wil Sinclair [ 02/Sep/08 10:39 AM ]
Updating for the 1.6.0 release.
[ZF-3081] [Zend_Mail_Protocol_Imap] Append message Created: 09/Apr/08                           Updated:
02/Sep/08 Resolved: 22/Apr/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       None
Fix Version/s:           1.6.0

Type:                    Bug                             Priority:              Major
Reporter:                Vincent Clair                   Assignee:              Nico Edtinger
Resolution:              Fixed                           Votes:                 0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
Hello,

I have found a bug in Imap protocol to append a message to a box.
Excuse me for my english, and i hope you will understand what i
mean.

Here is an example of a correct APPEND operation :

. APPEND user.pdupont {152}
+ go ahead
From:
To:
Subject: Les lapins d'Australie

Ne pas les confondre avec les kangourous.

. OK [APPENDUID 896443059 1408] Completed

But in "Zend_Mail_Protocol_Imap::append", it throw
"requestAndResponse", which "_assumedNextLine" with '+ OK'. But it
needs for APPEND '+ go ahead'. So to
resume :

send 'APPEND '. $folder .' {'. strlen($message) .'}';
waiting for '+ go ahead'
send $message

And of course, could the uid be return when we call $uid = $imap->appendMessage(...) ?

Thanks a lot,
Vincent




Comments
Comment by Wil Sinclair [ 18/Apr/08 03:48 PM ]
Please evaluate and categorize/assign as necessary.
Comment by Nico Edtinger [ 22/Apr/08 01:26 PM ]
Thanks. We now don't check for the response text, only for '+ '
Comment by Wil Sinclair [ 02/Sep/08 10:38 AM ]
Updating for the 1.6.0 release.
[ZF-3067] Zend_Mime::encodeQuotedPrintable's return is wrong if
passed cyrillic chars Created: 08/Apr/08 Updated: 02/Jan/09 Resolved: 02/Jan/09
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail, Zend_Mime
Affects Version/s:       1.5.1, 1.7.2
Fix Version/s:           1.7.3

Type:                    Bug                                 Priority:               Critical
Reporter:                Kostya L.                           Assignee:               Satoru Yoshida
Resolution:              Fixed                               Votes:                  0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Issue Links:             Dependency
                         depends on           ZF-2559      Email subject encoding bug                    Resolved
Fix Version Priority: Must Have

Description

           $sQuotedValue = Zend_Mime::encodeQuotedPrintable('новое приглашение');

returns

           =D0=BD=D0=BE=D0=B2=D0=BE=D0=B5
           =D0=BF=D1=80=D0=B8=D0=B3=D0=BB=D0=B0=D1=88= =D0=B5=D0=BD=D0=B8=D0=B5

You see there is a gap

           ==

which results in a broken email header.




Comments
Comment by Wil Sinclair [ 18/Apr/08 03:57 PM ]
Please evaluate and categorize/assign as necessary.
Comment by Kostya L. [ 21/Apr/08 09:15 AM ]
is something wrong w/ this issue submition?
Comment by Wil Sinclair [ 09/Jun/08 04:36 PM ]
Please evaluate and fix/categorize as necessary.
Comment by Wil Sinclair [ 09/Jun/08 04:37 PM ]
Nothing wrong with the submission. I just mistakenly assigned it to Fabien. Nico, please re-assign to Alex V. if this is
not something you can address.
Comment by Kostya L. [ 15/Oct/08 01:02 AM ]
Do you plan to fix this bug or not?
Comment by Satoru Yoshida [ 02/Jan/09 11:06 PM ]
I think new function of Zend_Mail, setEncodingOfHeader() will resolve your problem.
[ZF-2748] Incorrect @param order in Zend_Mail functions Created: 28/Feb/08
Updated: 17/Dec/08 Resolved: 28/Feb/08
Status:                 Closed
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.5.0RC1
Fix Version/s:          1.5.0

Type:                   Docs: Problem                    Priority:             Minor
Reporter:               Jordan Ryan Moore                Assignee:             julien PAULI
Resolution:             Fixed                            Votes:                0
Remaining Estimate: 5 minutes
Time Spent:             Not Specified
Original Estimate:      5 minutes

Language:               English
Fix Version Priority: Should Have

Description
Zend_Mail::addCc() and Zend_Mail:addTo() have their phpDoc @param's out of order:




Comments
Comment by julien PAULI [ 28/Feb/08 12:28 PM ]
fixed in r8449
Comment by Wil Sinclair [ 17/Dec/08 01:02 PM ]
Bookkeeping. Assigning all resolved issues to the people who resolved them. The only unassigned issues should be
those that are new and unreviewed.
[ZF-2684] Zend_Mail wrong encode of mail subject, if it contain
underscore Created: 18/Feb/08 Updated: 01/May/08 Resolved: 14/Apr/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.0.3
Fix Version/s:           1.5.2

Type:                    Bug                                   Priority:                 Major
Reporter:                Akira Matsuoka                        Assignee:                 Satoru Yoshida
Resolution:              Fixed                                 Votes:                    0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
I cannot decode mail subject in Japanese at OutlookExpress and Gmail.
I think encoding for '_' (underscore) is wrong.

function _encodeHeader()
$quotedValue = str_replace(array('?', ' '), array('=3F', '=20'), $quotedValue);

fix like this
$quotedValue = str_replace(array('?', ' ', '_'), array('=3F', '=20', '=5F'), $quotedValue);

I check correctly at OE and Gmail.

thank you

(Ref)
The "Q" encoding defined in RFC2047
4.2.2
The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be represented as "_" (underscore, ASCII 95.). (This
character may not pass through some internetwork mail gateways, but its use will greatly enhance readability of "Q"
encoded data with mail readers that do not support this encoding.) Note that the "_" always represents hexadecimal
20, even if the SPACE character occupies a different code position in the character set in use.




Comments
Comment by Satoru Yoshida [ 14/Apr/08 08:50 AM ]
Thank you for report. Fixed in SVN r9222
[ZF-2671] Zend_MailTest failing Created: 17/Feb/08                       Updated: 02/Sep/08 Resolved: 20/Mar/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      None
Fix Version/s:          1.6.0

Type:                   Bug                                  Priority:                Major
Reporter:               Sebastian Nohn                       Assignee:                Nico Edtinger
Resolution:             Fixed                                Votes:                   0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Dependency

Description
4) testHeaderEncoding(Zend_MailTest)
Failed asserting that <text> contains "From: =?iso-8859-
1?Q?"=E4=FC=F6=DF=C4=D6=DC"?=".
/home/darby/framework/trunk/tests/Zend/MailTest.php:184


Comments
Comment by Darby Felton [ 29/Feb/08 03:26 PM ]
I confirm this result to be occurring in the latest trunk (r8480, Linux, PHP 5.2.5, PHPUnit 3.2.15).
Comment by Wil Sinclair [ 12/Mar/08 01:28 PM ]
Nico, can we get this fixed for 1.5.1?
Comment by Wil Sinclair [ 02/Sep/08 10:39 AM ]
Updating for the 1.6.0 release.
[ZF-2624] Message-ID getter/setter Created: 12/Feb/08                         Updated: 14/Jan/09 Resolved: 08/Jan/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.3, 1.7.2
Fix Version/s:          1.7.3

Type:                   Improvement                          Priority:                Major
Reporter:               Gianluca Sforna                      Assignee:                Satoru Yoshida
Resolution:             Fixed                                Votes:                   0
Remaining Estimate: 0 minutes
Time Spent:             3 hours, 30 minutes
Original Estimate:      Not Specified

File Attachments:           ZF-2624.patch
Fix Version Priority: Nice to Have

Description
I'm evaluating moving Mantis issue tracker code (http://www.mantisbt.org ) from phpmailer to Zend::Mail.
When notification mails are sent from a mantis installation, the Message-ID is set in such a way that subsequent
mails coming from the same issue are threaded properly by email readers.

Right now, I can not find (neither in 1.5PR) any method for setting and getting the value of the Message-ID header,
so this is clearly a blocker, at least in my use case.




Comments
Comment by Wil Sinclair [ 18/Apr/08 03:48 PM ]
Please evaluate and categorize/assign as necessary.
Comment by Gianluca Sforna [ 19/Apr/08 03:03 AM ]
Will, I guess your comment is not addressed to me?
Comment by Wil Sinclair [ 04/Aug/08 08:17 AM ]
No. I was addressing Nico, who is the lead for the Zend_Mail component.
Would you like to fix this one yourself?
Comment by Gianluca Sforna [ 20/Aug/08 12:43 AM ]
The attached patch provides the required functions.

I am not sure if the setMessageId() method needs the same "sanitization" as you do in other header setters like
setSubject(); that would be trivial to add though
Comment by Gianluca Sforna [ 20/Aug/08 01:30 PM ]
Will, Nico, are there any chances this could be reviewed/pushed to SVN in time for 1.6 gold?
Comment by Gianluca Sforna [ 09/Sep/08 07:34 AM ]
Ok, now that 1.6 is released, are you able to assign a target version to this?
Comment by Nico Edtinger [ 12/Sep/08 12:48 PM ]
Hadn't much time lately, but my current target for most mail issues is 1.7.

One question about this. You say you want the mails to be in the correct thread. Wouldn't it be more correct to add a
message-id to the references header? I don't know how you decide to which thread a message belongs, but it seems
like you'd sending several messages with the same message-id, which is not correct.
Comment by Gianluca Sforna [ 13/Sep/08 07:59 AM ]
Yes, re-reading the description I realize the wording was not really clear.

Basically, the first mail we send on bug creation has a Message-ID composed from some unique data about the bug
(ID, creation timestamp, etc).

When notes are added or other events trigger a mail to be sent, we are able to set a "In-Reply-To" header with the
original Message-ID, and threading works as expected.
Comment by Gianluca Sforna [ 12/Nov/08 02:27 PM ]
Anything more I can do here?
Comment by Gianluca Sforna [ 13/Dec/08 08:56 AM ]
ping...
Comment by Satoru Yoshida [ 03/Jan/09 07:30 AM ]
I think following is better.

1) At first , user calls enableMessageId() function that enables creating id before sending message.
for example,

public function enableMessageId($flag)
{
$this->_useMessageId = (boolean) $flag;
}

2)At second, user calls send method without calling creating id method.

send() method has creating message id logic,

if ($this->_useMessageId === true) { //Here is logic that creates message id. }

3) Thus, each time own id will be created without forgetting change value.
Comment by Nico Edtinger [ 03/Jan/09 06:23 PM ]
We can support both. Make it public function setMessageId($id = true)
If $id is null or false no message-id header is added, if it's true a new id is generated, else the given one is taken.
I didn't had the time to really look into the format for message-ids, but we already have to generate unique ids for
writing to maildir. If we could reuse the functionality (making it a static method in Zend_Mail), that would be great.
Comment by Gianluca Sforna [ 05/Jan/09 09:41 AM ]
Nico, I guess you did not notice my patch?
Comment by Satoru Yoshida [ 05/Jan/09 11:29 PM ]
Hi, Gianluca Sforna .
I will try to update this issue in next holiday
Comment by Gianluca Sforna [ 06/Jan/09 12:58 AM ]
Hi Satoru (I guess that's your first name... mine is Gianluca); nice to see some activity here!


I just hope the next holiday where you live is not next Christmas

Feel free to let me know if/how my patch should be revised and I can provide you an updated one.
Comment by Satoru Yoshida [ 08/Jan/09 08:50 AM ]
Solved in SVN r13555

I added 4 methods.

setMessageId, getMessageId, clearMessageId, createMessageId.

Hi, Gianluca
Thank you for your kindness, but never mind.
I am not in the Orthodox church, a Buddhist

I will be happy if you try new functions!
Comment by Satoru Yoshida [ 14/Jan/09 09:29 PM ]
Additional Fix in SVN r13643.

Message-Id should be error on addHeader() function.
[ZF-2559] Email subject encoding bug Created: 04/Feb/08                              Updated: 10/Apr/09 Resolved: 02/Jan/09
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.0.3, 1.7.2
Fix Version/s:           1.7.3

Type:                    Bug                                   Priority:                Critical
Reporter:                Sergey Voyachek                       Assignee:                Satoru Yoshida
Resolution:              Fixed                                 Votes:                   0
Remaining Estimate: 0 minutes
Time Spent:              3 hours
Original Estimate:       Not Specified

File Attachments:           header.patch
Issue Links:             Dependency
                         is dependecy of      ZF-3067     Zend_Mime::encodeQuotedPrintable's re...             Resolved
                         is dependecy of      ZF-6267     remove deprecated functions                          Resolved
                         Related
                         is related to        ZF-6263     Bug in Zend_Mail subject in case of s...             Resolved
Fix Version Priority: Must Have

Description
I tried to send letter using charset 'cp1251' or 'win1251'. For this purpose I created new instance of Zend_Mail passed
this charset in constructor. Then called functions setSubject and setBodyHtml pointed my message.
$mail = new Zend_Mail('cp1251');
$mail->setSubject('Поздравляем с успешной регистрацией');
$mail->setBodyHtml("<b>Blah-blah</b>");

Receved message has problem with subject.
The subject has useless symbol.
GMail: 'Поздравляем с успешной рег_истрацией' ('_' means space)
Yandex: 'Поздравляем с успешной рег=истрацией' ('' means space)
Mail.ru: 'Поздравляем с успешной регE8истрацией'

I think that problem happened around cyrillic symbols.

Thank you!




Comments
Comment by Jonathan Bond-Caron [ 08/Feb/08 12:11 PM ]
protected function _encodeHeader($value)
{
if (Zend_Mime::isPrintable($value)) { return $value; } else { return '=?' . $this->_charset . '?B?' .
Zend_Mime::encodeBase64($value) . '?='; }

This should fix your problem, the problem is Zend_Mime::encodeQuotedPrintable looks buggy so I used a B encode
(base64) on the subject . This was the quick fix for me, I'll try to put togheter a patch and fix
Zend_Mime::encodeQuotedPrintable.
Comment by Wil Sinclair [ 17/Dec/08 01:30 PM ]
Was this fixed in the repository? If not, this should probably be marked 'won't fix'.
Comment by Wil Sinclair [ 17/Dec/08 01:31 PM ]
Please verify resolved status.
Comment by Sergey Voyachek [ 18/Dec/08 01:57 AM ]
I wrote the same patch and problem was resolved.
Comment by Jonathan Bond-Caron [ 18/Dec/08 06:31 AM ]
The patch
Comment by Jonathan Bond-Caron [ 18/Dec/08 06:35 AM ]
I attached the 'quick fix' patch, please commit

Another issue should probably be opened for Zend_Mime::encodeQuotedPrintable, more testing with utf-8?
Comment by Satoru Yoshida [ 02/Jan/09 10:54 PM ]
Solved in SVN r13496.

1) Change _encodeHeader() can encode by not only quotedPrintable but also by Base64.

2) Add $_encodingOfHeaders and setter/getter functions.
Comment by Satoru Yoshida [ 23/Jan/09 06:46 AM ]
I changed the name to $_headerEncoding
[ZF-2534] A exception was threw in the Zend_Mail_Transport_Smtp's
method __destruct. Created: 31/Jan/08 Updated: 17/Nov/09 Resolved: 17/Nov/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.3
Fix Version/s:          None

Type:                   Bug                                 Priority:                 Major
Reporter:               Xing Xing                           Assignee:                 Satoru Yoshida
Resolution:             Duplicate                           Votes:                    1
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Duplicate
                        duplicates      ZF-2075    Exception in destructor Zend_Mail_Tra...            Resolved

Description
First, look here
http://bugs.php.net/bug.php?id=33598&edit=1
this is the php's bug.

And in the line 139:

public function __destruct()
    {
        if ($this->_connection instanceof Zend_Mail_Protocol_Smtp) {
            $this->_connection->quit();
            $this->_connection->disconnect();
        }
    }

We will get: Fatal error: Exception thrown without a stack frame in Unknown on line
0

The real exception is: No connection has been established to smtpserver




Comments
Comment by Satoru Yoshida [ 01/Sep/08 06:06 PM ]
This issue may be outdated. I can not find the functions that are pointed out.
Comment by Marcos Gil Fuertes [ 29/Sep/09 06:53 AM ]
I'm having the same problem (Fatal error: Exception thrown without a stack frame in Unknown on line 0) with version
1.0.4.

Class: Zend_Mail_Transport_Smtp
Line: 139
Comment by Marcos Gil Fuertes [ 29/Sep/09 07:02 AM ]
I guess the connection is already closed and the call to:

$this->_send('QUIT');

At Zend_Mail_Protocol_Smtp, line 364, throws an exception (same Class, line 260):

protected function _send($request)
{
if (!is_resource($this->_socket)) { require_once 'Zend/Mail/Protocol/Exception.php'; throw new
Zend_Mail_Protocol_Exception('No connection has been established to ' . $this->_host); }
...
Comment by Satoru Yoshida [ 29/Sep/09 06:05 PM ]

reopen it for Marcos
Comment by Satoru Yoshida [ 14/Nov/09 06:27 AM ]
Memo: Zend_Mail_Protocol_Abstract has _send() .
Comment by Satoru Yoshida [ 17/Nov/09 02:36 PM ]
I search over SVN trunk today and find same problem was fixed at SVN r6661 (2007/10/20).

The change was done for .
The issue was solved in Ver 1.5.0.

I suggest you update your version to the latest to solve this issue.
[ZF-2532] Wrong encoded of the subject, if the subject is longer than
Zend_Mime::LINELENGTH. Created: 31/Jan/08 Updated: 06/Oct/08 Resolved: 06/Oct/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.3
Fix Version/s:          None

Type:                   Bug                                   Priority:                Major
Reporter:               Xing Xing                             Assignee:                Nico Edtinger
Resolution:             Duplicate                             Votes:                   10
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:          ZF-2532.patch
Issue Links:            Duplicate
                        duplicates       ZF-1688       Long header lines containing non-prin...          Resolved
                        Related
                        is related to    ZF-3912       Incorrect encoding of 'subject' in Ch...          Resolved

Description
In Zend_Mail::_encodeHeader() and Zend_Mail::setSubject().

Now, it is:
=?utf-
8?Q?mikespook=20=E9=82=80=E8=AB=8B=E6=82=A8=E9=80=B2=E5=85=A5=20ecbattle.net=20=E7=?=9A=84=E
4=B8=96=E7=95=8C=E5=85=A7?=

But should be:
=?utf-8?Q?mikespook=20=E9=82=80=E8=AB=8B=E6=82=A8=E9=80=B2=E5=85=A5=20ecbattle.net=20=E7=?=
=?utf-8?Q?9A=84=E4=B8=96=E7=95=8C=E5=85=A7?=

And if I modify the code in Zend/Mail.php line: 392.

protected function _encodeHeader($value)
{
if (Zend_Mime::isPrintable($value)) { return $value; } else { $quotedValue =
Zend_Mime::encodeQuotedPrintable($value); $quotedValue = str_replace(array('?', ' '), array('=3F', '=20'),
$quotedValue); return '=?' . $this->_charset . '?Q?' . $quotedValue . '?='; }
}

to:

protected function _encodeHeader($value)
{
if (Zend_Mime::isPrintable($value)) { return $value; } } else { $quotedValue =
Zend_Mime::encodeQuotedPrintable($value, 200); $quotedValue = str_replace(array('?', ' '), array('=3F', '=20'),
$quotedValue); return '=?' . $this->_charset . '?Q?' . $quotedValue . '?='; }
}
there will be no problem. but if it is longer than 200, the subject will be showed hash.




Comments
Comment by Xing Xing [ 31/Jan/08 12:59 AM ]
In the version 1.5, it also has this issue.
Comment by Ovidiu Curcan [ 19/Feb/08 12:12 PM ]
I ran into the same probkem while trying to send a newsletter. I came up with a quick & dirty fix (see below). It's a bit
of a hack and it only works for the subject (not for other headers). Problems go deeper.

Patch to be applied agains ZF 1.0.3:

--- Zend/Mail.php       2007-09-08 17:59:21.000000000 +0300
+++ Zend/Mail.php       2008-02-17 13:12:32.000000000 +0200
@@ -389,8 +389,9 @@
       if (Zend_Mime::isPrintable($value)) {
           return $value;
       } else {
-          $quotedValue = Zend_Mime::encodeQuotedPrintable($value);
+          $quotedValue = Zend_Mime::encodeQuotedPrintable($value, 60);
           $quotedValue = str_replace(array('?', ' '), array('=3F', '=20'),
$quotedValue);
+          $quotedValue = str_replace("=\n", "?=\n=?". $this->_charset .
'?Q?', $quotedValue);
           return '=?' . $this->_charset . '?Q?' . $quotedValue . '?=';
       }
     }
@@ -577,7 +578,14 @@
         if ($this->_subject === null) {
             $subject = strtr($subject,"\r\n\t",'???');
             $this->_subject = $this->_encodeHeader($subject);
-            $this->_storeHeader('Subject', $this->_subject);
+            $subjectPieces = explode("\n", $this->_subject);
+            $this->_storeHeader('Subject', $subjectPieces[0]);
+            unset($subjectPieces[0]);
+            if ($subjectPieces) {
+                 foreach ($subjectPieces as $piece) {
+                     $this->_storeHeader('Subject', $piece, true);
+                 }
+            }
         } else {
             throw new Zend_Mail_Exception('Subject set twice');
         }
Comment by Wil Sinclair [ 18/Apr/08 03:48 PM ]
Please evaluate and categorize/assign as necessary.
Comment by James Dempster [ 18/Apr/08 04:43 PM ]
From what I could work out, a problem with encoding occurs when the subject line is greater than 75 chars and UTF8
chars of 2 or more bytes are being used. The subject line then needs to be split on to multiple lines if this split occurs
in the middle of a quoted printable character i.e. between byte one and two the subject line breaks.

The easiest solution would be to use php iconv_mime_encode, but I found this to have a problem for quoted printable
(Q Encoded) subject lines that where quote long. This is a bug in php it's self.
I've supplied a patch which is as far as I've gotten with the problem so far. I've tried to reproduce what
iconv_mimie_encode would do for the Q encoding scheme. I think more evaluation testing and input is needed.

Also I've started to make the encoding technique usable by addTo for users whom have an alias in UTF8 encoded
characters.

I've so far tested that this works with Thunderbird and Gmail (with what I understand the standards to be).

More feedback please.
Comment by Adam Myszak [ 12/Jun/08 11:44 PM ]
hello.
In my opinion the bug is in the '_storeHeader()' method of Zend_Mail class.
I don't know why is there a instruction: $value = strtr($value,"\r\n\t",'???'); ?
The specification of ARPA (RFC 2822) don't accept char '?' for divide a header.
You should change that instruction to replace char '?' for another.
[ZF-2439] Zend_Mail_Storage_Pop3 method getUniqueId does not work
properly when there are no messages on the server and UIDL extension
is unsupported Created: 15/Jan/08 Updated: 21/Mar/08 Resolved: 21/Jan/08
Status:               Resolved
Project:              Zend Framework
Component/s:          Zend_Mail
Affects Version/s:    1.0.3
Fix Version/s:        1.5.0

Type:                 Bug                                Priority:               Major
Reporter:             Chris Utz                          Assignee:               Nico Edtinger
Resolution:           Fixed                              Votes:                  0
Remaining Estimate: Not Specified
Time Spent:           Not Specified
Original Estimate:    Not Specified

Fix Version Priority: Must Have

Description
The following is the code of the getUniqueId method in Zend_Mail_Storage_Pop3:

public function getUniqueId($id = null)
{
    if (!$this->hasUniqueid) {
        if ($id) {
            return $id;
        }
        $range = range(1, $this->countMessages());
        return array_combine($range, $range);
    }

     return $this->_protocol->uniqueid($id);
}

Note the call to the range function. According to the PHP documentation, range() will generate a descending
sequence if the 2nd parameter is smaller. The getUniqueId method depends on range returning an empty array if
countMessages returns 0, which it does not.

The following code works as intended:

public function getUniqueId($id = null)
{
    if (!$this->hasUniqueid) {
        if ($id) {
            return $id;
        }

            $numMessages = $this->countMessages();

            if ($numMessages == 0) {
                return array();
            } else {
                $range = range(1, $numMessages);
                return array_combine($range, $range);
            }
      }

      return $this->_protocol->uniqueid($id);
}

NB - I've checked the problem is still present in the trunk.
[ZF-2413] "to" field should not be mandatory when a cc or bcc is set
Created: 11/Jan/08 Updated: 21/Jan/08 Resolved: 21/Jan/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.0.3
Fix Version/s:           None

Type:                    Bug                                  Priority:               Major
Reporter:                Andries Seutens                      Assignee:               Nico Edtinger
Resolution:              Won't Fix                            Votes:                  1
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Fix Version Priority: Should Have

Description
The "to" field should not be mandatory when a cc or bcc is set.
Currently, when not setting a "to" field, but providing a bcc or cc, an exception is thrown:

Fatal error: Uncaught exception 'Zend_Mail_Transport_Exception' with message 'Missing To header' in
/libs/Zend/Mail/Transport/Sendmail.php:133




Comments
Comment by Michal Minicki [ 14/Jan/08 09:56 AM ]
As per RFC 2822, page 18:
http://www.ietf.org/rfc/rfc2822.txt
Comment by Nico Edtinger [ 21/Jan/08 12:19 PM ]
That's only true for the sendmail transport. It uses the php function mail() and
http://php.net/manual/en/function.mail.php doesn't say it's optional or how it behaves if it's an empty string.

It does say it must comply with RFC 2822 and I can only assume they mean address-list. As addr-spec, which is part
of address-list has a literal @ the empty string would not be valid.

The SMTP transport does not have this problem.

Therefore RFC 2822 is not the problem here, but mail(), which does explicitly write a To header.
[ZF-2378] A "new " miss in the example code Created: 04/Jan/08                                Updated: 21/Mar/08
Resolved: 21/Jan/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       None
Fix Version/s:           1.5.0

Type:                    Docs: Problem                      Priority:                 Minor
Reporter:                Bonneau Pierre                     Assignee:                 Nico Edtinger
Resolution:              Fixed                              Votes:                    0
Remaining Estimate: 5 minutes
Time Spent:              Not Specified
Original Estimate:       5 minutes


Description
In the documentation of Zend Mail, on the "reference guide", point 21.14.5.

The code is :

           foreach (RecursiveIteratorIterator($mail->getMessage(1)) as $part) {
           try {
           if (strtok($part->contentType, ';') == 'text/plain') {
           $foundPart = $part;

And it must be :

           foreach (new RecursiveIteratorIterator($mail->getMessage(1)) as $part) {
           try {
           if (strtok($part->contentType, ';') == 'text/plain') {
           $foundPart = $part;

Thanks you
Pierre Bonneau
QSMS




Comments
Comment by Wil Sinclair [ 15/Jan/08 04:39 PM ]
Matthew, you have some other documentation fixes for 1.5, can you take a look at this one, too?
[ZF-2324] Corrupt attachments with MS Exchange/Outlook Created: 18/Dec/07
Updated: 13/Nov/08 Resolved: 06/Nov/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail, Zend_Mime
Affects Version/s:      1.0.3
Fix Version/s:          1.7.0

Type:                   Bug                                  Priority:                Major
Reporter:               Justin Hendrickson                   Assignee:                Thomas Weidner
Resolution:             Fixed                                Votes:                   7
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
Attachments, sent by Zend_Mail to mailboxes on MS Exchange servers and retrieved with Outlook, are corrupt.

The initial conversations about the bug can be found here:
http://www.nabble.com/Zend_Mail-and-Microsoft-Exchange-Servers-td14180559s16154.html#a14180559

Two different users also reported the same fix for the problem:
http://www.nabble.com/Re%3A-Zend_Mail-and-Microsoft-Exchange-Servers-p14372427s16154.html
http://www.nabble.com/Re%3A-Zend_Mail-and-Microsoft-Exchange-Servers-p14396692s16154.html

Each user changed the LINELENGTH in Zend_Mime from 74 to 72, which resolved the problem.




Comments
Comment by Paul Menheere [ 31/Mar/08 09:18 AM ]
It also affects version 1.5 and seems to be the problem with Microsoft SBS 2003 as mailtransport.
Comment by Justin Hendrickson [ 13/Apr/08 01:21 PM ]
This has been sitting out here for quite a while with no resolution and it's a very simple fix. If there's concern about
breaking existing functionality, could we at least make th line length customizable, but defaults to 74, so those of us
that need this change can actually use the mail library?
Comment by Wil Sinclair [ 18/Apr/08 03:48 PM ]
Please evaluate and categorize/assign as necessary.
Comment by Jeremy Coates [ 10/May/08 03:22 AM ]
Just done some testing with one of our clients who has been seeing this corruption for every PDF attached.

Their environment Win2K3 server, Exchange 2K3 (v6.5.76381), XP & Vista Clients Outlook 2K3

Width 74 - PDF files arrive corrupted every time
Width 72 - PDF files arrive as expected

Impact on other clients - non noticeable - e.g. SBS Exchange / Outlook 2K3, Thunderbird (multi-platform), Gmail,
Hotmail, Yahoo! all work fine.
I'd suggest we move to 72 width as the default (or at least have a configurable option as suggested).
Comment by Jeremy Coates [ 10/May/08 03:24 AM ]
Just to confirm, this is still an issue with 1.5.x ZF.
Comment by Jeremy Coates [ 12/May/08 12:58 AM ]
Further investigation seems to indicate switching to 72 is fine for PDFs but not e.g. Zip files.

Perhaps there's a wider issue at work?!
Comment by Frederic Marchal [ 10/Jun/08 03:01 AM ]
Our customers have encountered this corruption for every file attached, not only PDF.

Their environment is : Exchange v6.5, Outlook 2K3

I read the source of ezc, PHPmailer class and PEAR::Mail, and I found they all use a line length of 76.

So, I changed the constant LINELENGTH (line 41 of Mime.php) to 76, and it works well for every attachments.
I do not tried zip files.
Comment by Karol Grecki [ 02/Sep/08 03:56 AM ]
There's a hotfix for it at http://support.microsoft.com/default.aspx?scid=kb;EN-US;937625
It would still be nice to have some workaround for it as most corporate users won't install it untill next service pack is
released.
Comment by Thomas Weidner [ 06/Nov/08 01:06 PM ]
Fixed with r12343.
Changed linelength to 72 to be compatible with other mailers.
Comment by Wil Sinclair [ 13/Nov/08 02:10 PM ]
Changing issues in preparation for the 1.7.0 release.
[ZF-2219] addBcc() lacks 'name' parameter Created: 20/Nov/07                               Updated: 02/Dec/10 Resolved:
02/Dec/10
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.3
Fix Version/s:          Next Major Release

Type:                   Improvement                          Priority:                Minor
Reporter:               Daan Broekhof                        Assignee:                Dolf Schimmel (Freeaqingme)
Resolution:             Fixed                                Votes:                   1
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:             Related
                         is related to   ZF-8527     Augment Zend_Mail recipient functions...                Resolved
                         is related to   ZF-9921     Zend_Mail: Allow multiple ReplyTo add...                Resolved
Fix Version Priority: Nice to Have

Description
The addBcc() function does not have the second parameter 'name' , while addCc() and addTo() do have it .
Instead the name is internally set to ''.

For consistency & usablities sake addBcc() should also get the extra name parameter.




Comments
Comment by Nico Edtinger [ 15/Dec/07 10:01 AM ]
To and CC have corresponding headers, while BCC doesn't. BCC is only used for the envelope and the name
wouldn't be used anyway. If you want to, you could still call BCC with an extra parameter, as it's ignored by PHP.
Comment by Daan Broekhof [ 15/Dec/07 11:12 AM ]
Ah I see what you mean when it just purely concerns sending the mail to the recipients..

But when you want to store the mail somewhere, say in an IMAP 'sent' folder, or display it, say in a 'preview' area,
that BCC 'name' data is lost - data which is a valid part of the BCC header.

Would it not be better to let Zend_Mail retain the complete information, and leave it up to the 'handlers' of the mail
object to use only the data which they need?
Comment by Nico Edtinger [ 03/Jan/08 04:20 PM ]
I'll see. That would make sense when we merge the mail messages classes or add some better support to copy a
sent message to imap or maildir. Therefore this issue is now postponed.
Comment by Satoru Yoshida [ 09/Jun/10 12:25 AM ]
Sorry, I have been inactive since last April.
Comment by Dolf Schimmel (Freeaqingme) [ 02/Dec/10 07:21 PM ]
Resolved for ZF2
[ZF-2187] Zend_mail unitests crash on i5/OS Created: 13/Nov/07                                    Updated: 18/Jun/08
Resolved: 18/Jun/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.2
Fix Version/s:          None

Type:                   Unit Tests: Problem                   Priority:                Critical
Reporter:               Shany Ron                             Assignee:                Nico Edtinger
Resolution:             Cannot Reproduce                      Votes:                   0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:             Dependency
                         Related
                         is related to    ZF-3073      Set up i5 testing environment devoted...                   Closed

Description
This error occurs only on i5/OS (both OS version v5R3 and v5R4) and didn't occur on Windows or Linux.

I ran AllTests.php on i5 with ZendCore 2.5.0 and bundled ZendFramework 1.02. When it got to the
"Zend_Mail_InterfaceTest" I got segmentation fault crash. I guess it's on the test that wasn't in the report (I ran the
tests with --log-tap), which is "testIterationWithSeek". Below you can find the report on the last test suite.

           #TestSuite "Zend_Mail_InterfaceTest" started.
           ok 2021 - testCount(Zend_Mail_InterfaceTest)
           not ok 2022 - Error: testIsset(Zend_Mail_InterfaceTest)
           ok 2023 - testNotIsset(Zend_Mail_InterfaceTest)
           not ok 2024 - Error: testArrayGet(Zend_Mail_InterfaceTest)
           ok 2025 - testArraySetFail(Zend_Mail_InterfaceTest)
           not ok 2026 - Error: testIterationKey(Zend_Mail_InterfaceTest)
           not ok 2027 - Error:
           testIterationIsMessage(Zend_Mail_InterfaceTest)
           not ok 2028 - Error: testIterationRounds(Zend_Mail_InterfaceTest)



Comments
Comment by Ziv Perry [ 29/Nov/07 06:18 AM ]
Plz check the mail function on the i5 machine. It's probably the mail() function that raise this error (as far as i checked,
the mail function doesn't work properly on the i5 machine).
Comment by Nico Edtinger [ 21/Jan/08 03:39 PM ]
I don't have i5/OS, so I need a little help. The test you mentioned uses the LimitIterator. Does this crash? What's the
output?

<?php
var_dump(_LINE_);
$array = array(1, 2, 3, 4, 5);
var_dump(_LINE_);
$a = new ArrayIterator($array);
var_dump(_LINE_);
$l = new LimitIterator($a, 2, 2);
var_dump(_LINE_);
foreach ($l as $k => $v) {
var_dump(_LINE_, $k, $v);
}
var_dump(_LINE_);
?>
Comment by Nico Edtinger [ 21/Jan/08 03:42 PM ]
Note: it should be

__LINE__
with two underscores before and after LINE
Comment by Darby Felton [ 08/Apr/08 12:19 PM ]
Shany, any comment on this?
Comment by Nico Edtinger [ 18/Jun/08 10:40 AM ]
no feedback
[ZF-2163] Zend_Mail_Protocol_Abstract::_send() throw's an exception
without loading the Zend_Mail_Protocol_Exception class Created: 07/Nov/07
Updated: 19/Dec/08 Resolved: 13/Dec/07
Status:                 Closed
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.2
Fix Version/s:          None

Type:                   Bug                              Priority:             Blocker
Reporter:               Dennis Becker                    Assignee:             Jordan Ryan Moore
Resolution:             Not an Issue                     Votes:                1
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Fix Version Priority: Must Have

Description
I tried to send an email with Zend_Mail and changed from sendmail to smtp. I got an HTTP 501 error and the
Zend_Mail_Protocol_Abstract class throws an Zend_Mail_Protocol_Exception exception which has not been loaded
before. The Zend_Mail_Protocol_Abstract class misses a require_once('Zend/Mail/Protocol/Exception.php');




Comments
Comment by Jordan Ryan Moore [ 12/Dec/07 03:42 PM ]
Which line is the exception thrown from?
Comment by Dennis Becker [ 13/Dec/07 01:37 AM ]
I think this issue can changed to "closed" because I used the Zend_Mail component wrong. I checked my code with
the implementation of others and fixed it by myself. Sorry for this issue, that was only my fault.
Comment by Wil Sinclair [ 19/Dec/08 02:35 AM ]
Bookkeeping. Assigning closed and resolved issues to those who resolved them. The only unassigned issues should
be new and unreviewed.
[ZF-2155] Sending Multiple Mails per SMTP Connection example doesn't
work Created: 06/Nov/07 Updated: 19/Dec/08 Resolved: 05/Dec/07
Status:                 Closed
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.2
Fix Version/s:          None

Type:                   Docs: Problem                     Priority:              Major
Reporter:               Jack Sleight                      Assignee:              Jack Sleight
Resolution:             Duplicate                         Votes:                 0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Duplicate
                        duplicates      ZF-1737   Zend_Mail_Transport example for multi...          Resolved
Language:               English

Description
The code example on this page doesn't work: http://framework.zend.com/manual/en/zend.mail.multiple-emails.html .

"Call to undefined method Zend_Mail_Transport_Smtp::connect()"




Comments
Comment by Jack Sleight [ 05/Dec/07 08:40 AM ]
Duplicate of
Comment by Wil Sinclair [ 15/Jun/08 08:57 PM ]
Changing to comply with new IT coventions for components.
Comment by Wil Sinclair [ 19/Dec/08 02:39 AM ]
Bookkeeping. Assigning closed and resolved issues to those who resolved them. The only unassigned issues should
be new and unreviewed.
[ZF-2114] wrong headers EOL for DATA part in SMTP Protocol Created:
30/Oct/07 Updated: 18/Jan/08 Resolved: 18/Jan/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.0.2
Fix Version/s:           None

Type:                    Bug                                Priority:                Major
Reporter:                Gabriele Santini                   Assignee:                Simon Mundy
Resolution:              Fixed                              Votes:                   1
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
Headers for emails which transport is set to Smtp are separated by the function _prepareHeaders with the $EOL
property which is set to "\n" in Zend_Mail_Transport_Smtp.

The same headers are parsed by the data method in Zend_Mail_Protocol_Smtp and exploded by a self::EOL class
constant.
This constant is declared in Zend_Mail_Protocol_Abstract as equal to "\r\n".
This results in not separating headers and in the residual presence of '0A' characters between headers lines instead
of the expected '0D0A'.

This can cause problems with some email servers respecting strict standards.

The solution I see is to declare the class constant EOL for Zend_Mail_Protocol_Smtp as equal to "\n" in accord with
the $EOL declaration in Zend_Mail_Transport_Smtp class.




Comments
Comment by Simon Mundy [ 05/Nov/07 08:02 PM ]
The data parsed in the data() method in ZF 1.0.2 is exploded via Zend_Mime::LINEEND - are you using the most
recent revision of the Mail components?
Comment by Gabriele Santini [ 05/Nov/07 10:17 PM ]
Thank you for your answer.

I'm just using version 1.0.2.

I'm talking about line 288 in Zend_Mail_Protocol_Smtp and the 'exploder' I see is self::EOL
Comment by Simon Mundy [ 05/Nov/07 10:34 PM ]
This change was already fixed in trunk but looks like it missed out being included for ZF 1.0.2. Try replacing these
components with the latest versions from the nightly snapshot or update your repository using subversion and you'll
see the fix.
Comment by Simon Mundy [ 18/Jan/08 09:36 PM ]
No further evidence of bug - please re-open only if using newer ZF 1.0.3 release and condition still exists.
[ZF-2110] No Date header is added to mail messages before sending
Created: 29/Oct/07 Updated: 21/Mar/08 Resolved: 21/Jan/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.2
Fix Version/s:          1.5.0

Type:                   Bug                                  Priority:           Major
Reporter:               Nico Edtinger                        Assignee:           Nico Edtinger
Resolution:             Fixed                                Votes:              0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:          Mail.php.patch
Fix Version Priority: Should Have

Description
If a date header is not set while assembling the message it needs to be added before sending.

<mailing list thread>

From: KyleMac <nabble@deletethetrees.com>
Subject: Re: [fw-general] Zend_Mail

I was just looking into this missing date header thing since it caused a few
emails to bounce. From what I can tell, the MTA is under no obligation to
add the date header and in Exim it's considered a "fixup" (or rather, not
doing it is called suppressing fixups). Short story; if your MTA adds it
then it's being kind, if not then it's your fault for not doing it yourself.

Considering the date header is meant to be a requirement, I think that maybe
it deserves at least a mention in the ZF manual, maybe it's own addDate()
method and probably to be added automatically by Zend_Mail.

Matthew Weier O'Phinney-2 wrote:
>
> On 7/6/06, Brent Robinson <brent@arquila.com> wrote:
>> I am having a problem with Zend_Mail that my mail is not passing a date
>> header. I am getting a 01/01/1970 date in thunderbird and a unknown date
>> in Webmail.
>>
>> I am using SMTP and am developing on a Windows Platform with Apache 2
>> and PHP5.
>
> <snip>
>
>> Is there something that I am overlooking or am not setting. I have
>> looked and googled the whole afternoon but cannot find anything.
>
> Date headers are usually set by the mail transport; if you're not seeing
> one, then your transport isn't putting it in (which is bad behaviour on
> the part of the transport).
>
> Two options: investigate your mail transport and see why it's not
> setting the date header, or set it manually using Zend_Mail's
> addHeader() method:
>
> $mail->addHeader('Date', date('r'));
>
> What are you using for mail delivery, by the way? You mention SMTP, but
> you don't specify what kind of SMTP server you're using. Others may be
> able to point out additional remedies based on that information.
>
</mailing list thread>

From RFC 2822: "[The origination date specifies] the time at which the human or other creator of the message has
put the message into its final form, ready for transport."




Comments
Comment by Jordan Ryan Moore [ 13/Dec/07 06:29 PM ]
Attached a patch that adds new setDate()/getDate() methods. If a date is not set before send()ing, it's automatically
set.
Comment by Wil Sinclair [ 15/Jan/08 05:31 PM ]
Nico, will you have time to get to this by the PR code freeze (1/22)?
Comment by Nico Edtinger [ 21/Jan/08 01:41 PM ]
Thanks Jordan for the patch. It's added to trunk, with some modifications and should be fully tested (don't have
xdebug installed here).
[ZF-2080] Zend_Mail::getPartCount() - wrong datatype defined as return
value in phpdoc Created: 17/Oct/07 Updated: 21/Mar/08 Resolved: 19/Oct/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.2
Fix Version/s:          1.5.0

Type:                   Patch                               Priority:   Trivial
Reporter:               Jan Pieper                          Assignee:   Nico Edtinger
Resolution:             Fixed                               Votes:      0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:          getPartCount.diff

Description
phpdoc says getPartCount() returns void, but it returns an integer.




Comments
Comment by Jan Pieper [ 17/Oct/07 04:33 AM ]
Added diff to fix wrong phpdoc.
Comment by Thomas Weidner [ 17/Oct/07 09:57 AM ]
Assigned to Nico
[ZF-2076] Exception in destructor Zend_Mail_Transport_Smtp Created: 16/Oct/07
Updated: 19/Oct/07 Resolved: 19/Oct/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.2
Fix Version/s:          None

Type:                   Bug                                 Priority:               Major
Reporter:               Alexis Vannier                      Assignee:               Nico Edtinger
Resolution:             Duplicate                           Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Duplicate
                        duplicates       ZF-2075    Exception in destructor Zend_Mail_Tra...            Resolved

Description
A Zend_Mail_Protocol_Exception is thrown in class Smtp::__destruct() if you can't disconnect properly, but throwing
an exception from a destructor causes a fatal error with the following message : "Fatal error: Exception thrown
without a stack frame in Unknown on line 0"

Code throwing this error :
abstract class Zend_Mail_Protocol_Abstract {
[...]
public function __destruct() { $this->_disconnect(); }
[...]
}




Comments
Comment by Thomas Weidner [ 17/Oct/07 09:56 AM ]
Assigned to Nico
[ZF-2075] Exception in destructor Zend_Mail_Transport_Smtp Created: 16/Oct/07
Updated: 17/Nov/09 Resolved: 19/Oct/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.2
Fix Version/s:          1.5.0

Type:                   Bug                                  Priority:              Major
Reporter:               Alexis Vannier                       Assignee:              Nico Edtinger
Resolution:             Fixed                                Votes:                 0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Duplicate
                        is duplicated by     ZF-2076     Exception in destructor Zend_Mail_Tra...        Resolved
                        is duplicated by     ZF-2534     A exception was threw in the Zend_Mai...        Resolved

Description
A Zend_Mail_Protocol_Exception is thrown in class Smtp::__destruct() if you can't disconnect properly, but throwing
an exception from a destructor causes a fatal error with the following message : "Fatal error: Exception thrown
without a stack frame in Unknown on line 0"

Code throwing this error :
abstract class Zend_Mail_Protocol_Abstract {
[...]
public function __destruct() { $this->_disconnect(); }
[...]
}




Comments
Comment by Thomas Weidner [ 17/Oct/07 09:55 AM ]
Assigned to Nico
[ZF-2074] Zend_mail lose dot in mail Created: 16/Oct/07                         Updated: 19/Oct/07 Resolved: 19/Oct/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.2
Fix Version/s:          None

Type:                   Bug                                  Priority:               Major
Reporter:               Christian Kaps                       Assignee:               Nico Edtinger
Resolution:             Duplicate                            Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Duplicate
                        duplicates      ZF-326    SMTP transport is not prepending dots...                 Resolved

Description
Hi

When i send a mail with this script the dot between christian and www in the result email will be lost.

set_include_path('/srv/apache/htdocs/user/christian/tests');

require_once('Zend/Loader.php');

function __autoload($className) {
   Zend_Loader::loadClass($className);
}

$body = 'ttttttttttttttttttttttttttttttttttt

ääätttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
tttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt

ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
http://christian.www.ttttttttttt.de';

try {
            $tr = new Zend_Mail_Transport_Smtp('localhost');
            Zend_Mail::setDefaultTransport($tr);

        $mailer = new Zend_Mail();
        $mailer->addTo('your@mail.com');
        $mailer->setFrom('reply@mail.com', 'Reply name');
        $mailer->setSubject('mail bug');
        $mailer->setBodyText($body);
        $mailer->send();
} catch (Exception $e) {
        throw new i21_Exception($e->getMessage());
}

This is the result email.

ttttttttttttttttttttttttttttttttttt

ääätttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
tttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt

ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
http://christianwww.ttttttttttt.de

Greets
Christian




Comments
Comment by Thomas Weidner [ 17/Oct/07 09:54 AM ]
Assigned to Nico
[ZF-2043] Unappealing From header Created: 04/Oct/07                         Updated: 13/Nov/08 Resolved: 07/Nov/08
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     1.0.0, 1.0.1, 1.0.2
Fix Version/s:         1.7.0

Type:                  Improvement                        Priority:                Minor
Reporter:              TechWeb SHQ                        Assignee:                Satoru Yoshida
Resolution:            Fixed                              Votes:                   2
Remaining Estimate: 0 minutes
Time Spent:            4 hours, 40 minutes
Original Estimate:     Not Specified

Issue Links:           Related
                       is related to     ZF-3912    Incorrect encoding of 'subject' in Ch...            Resolved

Description
When a letter is sent and the message does not provide a name
for the sender then the From-header is set with empty brackets.

$mail->setFrom('adress@mail.ca');

Results as
From : "" <adress@mail.ca>

One would expect the from-header not to include empty brackets "".

The setFrom function of the Zend_Mail class should be changed as follows

/**
* Sets From-header and sender of the message
*
* @param string     $email
* @param string     $name     optional
* @return Zend_Mail Provides fluent interface
* @throws Zend_Mail_Exception if called subsequent times
*/
public function setFrom($email, $name = '')
{
        if ($this->_from === null) {
            $email = strtr($email,"\r\n\t",'???');
            $this->_from = $email;

                 if ($name != '') {
                    $name = '"' . $this->_encodeHeader($name) . '" ';
                 }

                $this->_storeHeader('From', $name .' <'.$email.'>', true);
            } else {
                throw new Zend_Mail_Exception('From Header set twice');
             }
             return $this;
}


Comments
Comment by Thomas Weidner [ 15/Oct/07 02:04 PM ]
Assigned to Nico
Comment by Satoru Yoshida [ 07/Nov/08 08:22 AM ]
Solved in SVN r12370
Comment by Thomas Gelf [ 07/Nov/08 08:46 AM ]
As the second parameter is optional I suggest setting $name = null and verifying whether $name === null to be
conform with "PHP Coding Standard (draft) -> Optional Parameters".

One more thing: if name is given you're currently adding two spaces between name and email address. A possible
variant, IMO also easier to read could be:

public function setFrom($email, $name = null)
{
    if ($this->_from === null) {
        $email = strtr($email,"\r\n\t",'???');
        $this->_from = $email;

          if (null === $name) {
               $from = sprintf('"%s" ', $this->_encodeHeader($name));
          } else {
               $from = '';
          }
          $from .= sprintf('<%s>', (string) $email);
          $this->_storeHeader('From', $from, true);
      } else {
          ...

Cheers,
Thomas


Sorry for nitpicking, could not resist
Comment by Satoru Yoshida [ 07/Nov/08 10:51 AM ]
Hello, Thomas.
You are welcome.          Thank You for Your advice.

I refixed as following.

1) If $name is not used or the $name is same as $email,
header is "From: $email".

2) If $name is used and the $name is encoded,
header is "From: $name <$email>".

3) If $name is used and the $name is not encoded and not contains comma,
header is "From: $name <$email>".
4) If $name is used and the $name is not encoded and contains comma,
header is "From: "$name" <$email>".

Best Regards,
Satoru Yoshida
Comment by Thomas Gelf [ 07/Nov/08 12:51 PM ]
Great. One last note: Wouln't 1) better be From: <$email> ?

Regards,
Thomas Gelf
Comment by Thomas Gelf [ 07/Nov/08 03:16 PM ]
Sorry, my fault. "From: user@domain.tld" is correct.
Comment by Satoru Yoshida [ 07/Nov/08 05:44 PM ]
Hi, Thomas.

Thank You for checking my comment.

Yes, both "From: user@domain.tld" and "From: <user@domain.tld>" are correct.


I selected "From: user@domain.tld" on implementation.
Comment by Wil Sinclair [ 13/Nov/08 02:10 PM ]
Changing issues in preparation for the 1.7.0 release.
[ZF-1976] Remove BCC in SMTP transport Created: 21/Sep/07                              Updated: 21/Mar/08 Resolved:
19/Oct/07
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     1.0.1
Fix Version/s:         1.5.0

Type:                  Improvement                         Priority:               Minor
Reporter:              Nico Edtinger                       Assignee:               Nico Edtinger
Resolution:            Fixed                               Votes:                  0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified


Description
Not all SMTP servers remove a BCC header and it might therefor not be hidden from the normal recipients. As a
bonus it might be nice to be able to use all three BCC modes (remove, truncate to current recipient or empty value).
[ZF-1950] Correct method of encodeHeader "From" for Multibyte name
senders Created: 14/Sep/07 Updated: 13/Nov/08 Resolved: 07/Nov/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.0.2
Fix Version/s:           1.7.0

Type:                    Improvement                         Priority:                Major
Reporter:                Satoru Yoshida                      Assignee:                Satoru Yoshida
Resolution:              Fixed                               Votes:                   5
Remaining Estimate: 0 minutes
Time Spent:              10 minutes
Original Estimate:       Not Specified

Issue Links:             Duplicate
                         duplicates       ZF-1688     Long header lines containing non-prin...         Resolved
                         Related
                         is related to    ZF-1688     Long header lines containing non-prin...         Resolved
                         is related to    ZF-3912     Incorrect encoding of 'subject' in Ch...         Resolved

Description
I find following sentence in line 515 in Zend/Mail.php.

$this->_storeHeader('From', $this->_encodeHeader('"'.$name.'"').' <'.$email.'>', true);

But it causes error if Sender name contains Multibyte characters and Receiver uses OutlookExpress.
For example , I look in the $this , =?ISO-2022-JP?Q?"=1B$BAw=3F.<T=1B(B"?=.
I think it must be "=?ISO-2022-JP?Q?=1B$BAw=3F.<T=1B(B?=".

I propose to modify the line as next.
$this->_storeHeader('From', '"'.$this->_encodeHeader($name).'"<'.$email.'>', true);

I hope it will useful.




Comments
Comment by Thomas Weidner [ 15/Sep/07 03:03 PM ]
Assigned to Nico
Comment by Nico Edtinger [ 18/Sep/07 04:07 PM ]
Postponed because encoding will (most likely) be changed to iconv_mime_encode(), which should also fix this issue.
Comment by Satoru Yoshida [ 07/Nov/08 08:24 AM ]
Solved in SVN r12370
Comment by Wil Sinclair [ 13/Nov/08 02:10 PM ]
Changing issues in preparation for the 1.7.0 release.
[ZF-1945] Zend_Mail qp-encodes linefeeds Created: 13/Sep/07                              Updated: 06/Oct/08 Resolved:
06/Oct/08
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     1.0.1
Fix Version/s:         None

Type:                  Improvement                          Priority:              Minor
Reporter:              Stanislav Malyshev                   Assignee:              Nico Edtinger
Resolution:            Not an Issue                         Votes:                 1
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified

Issue Links:           Related
                       is related to   ZF-3912      Incorrect encoding of 'subject' in Ch...             Resolved

Description
When the message contains linefeeds and encoded as quoted-printable, Zend_Mail qp-encodes them as =0A. I think
it would be enough just putting \r\n there.




Comments
Comment by Thomas Weidner [ 15/Sep/07 03:08 PM ]
Assigned to Nico
Comment by James Dempster [ 06/Oct/08 08:49 AM ]
"If the data being encoded contains meaningful line breaks, they must be encoded as an ASCII CR LF sequence, not
as their original byte values. Conversely if byte values 10 and 13 have meanings other than end of line then they
must be encoded as =0A and =0D."
http://en.wikipedia.org/wiki/Quoted-printable

This is the way quoted printable should encode new lines.
[ZF-1944] Zend_Mail can't send mails to qmail server Created: 13/Sep/07                                   Updated:
15/Dec/07 Resolved: 06/Nov/07
Status:                    Resolved
Project:                   Zend Framework
Component/s:               Zend_Mail
Affects Version/s:         1.0.2
Fix Version/s:             1.0.3

Type:                      Bug                              Priority:               Major
Reporter:                  Stanislav Malyshev               Assignee:               Simon Mundy
Resolution:                Fixed                            Votes:                  2
Remaining Estimate: Not Specified
Time Spent:                Not Specified
Original Estimate:         Not Specified

Fix Version Priority: Must Have

Description
When trying to send mail to qmail server, this exception is produced:

Fatal error: Uncaught exception 'Zend_Mail_Protocol_Exception' with message '451 See
http://pobox.com/~djb/docs/smtplf.html .
' in /usr/local/lib/php/ZendFramework-1.0.0/library/Zend/Mail/Protocol/Abstract.php:351
Stack trace:
#0 /usr/local/lib/php/ZendFramework-1.0.0/library/Zend/Mail/Protocol/Smtp.php(297): Zend_Mail_Protocol_Abstract-
>_expect(250, 600)
#1 /usr/local/lib/php/ZendFramework-1.0.0/library/Zend/Mail/Transport/Smtp.php(199): Zend_Mail_Protocol_Smtp-
>data('From: "" <stas@...')
#2 /usr/local/lib/php/ZendFramework-1.0.0/library/Zend/Mail/Transport/Abstract.php(333):
Zend_Mail_Transport_Smtp->_sendMail()
#3 /usr/local/lib/php/ZendFramework-1.0.0/library/Zend/Mail.php(644): Zend_Mail_Transport_Abstract-
>send(Object(Zend_Mail))
#4 /root/mail.php(16): Zend_Mail->send()

qmail appears to be especially zealous about the cr/lf line endings, and it looks like Zend_Mail does not create the
correct ones.




Comments
Comment by Stanislav Malyshev [ 13/Sep/07 07:01 PM ]
Here is the script code:

<?php
require_once 'Zend/Mail/Transport/Smtp.php';
require_once 'Zend/Mail.php';
$tr = new Zend_Mail_Transport_Smtp('10.1.1.1');
Zend_Mail::setDefaultTransport($tr);
$mail = new Zend_Mail();
$mail->setFrom("stas@zend.com");
$mail->addTo("stas@zend.com");
$mail->setSubject('Activation Code - ');
$body .="\n\nPleasea activate your account.\n\n";
$body .="Confirmation Code: \n";
$body .="\n\n";
$body .= "Please confirm your account by copy/pasting following URL\n";
$body .= "\n\n\n";
$mail->setBodyText($body);
$mail->send();

10.1.1.1 is internal qmail server.
Comment by Stanislav Malyshev [ 13/Sep/07 07:11 PM ]
Looks like the problem is that when encoding to quoted-printable, the line ends are set as \n (0x0a) while they should
be \r\n (0x0d 0x0a). Apparently qmail hates that.
Comment by Thomas Weidner [ 15/Sep/07 03:02 PM ]
Assigned to Nico
Comment by Darby Felton [ 18/Sep/07 01:09 PM ]
Reducing priority to major
Comment by Simon Mundy [ 05/Nov/07 08:10 PM ]
Hi Stas - has this behaviour been resolved in 1.0.2 for you?
Comment by Stanislav Malyshev [ 06/Nov/07 01:51 AM ]
No, still happens in 1.0.2
Comment by Simon Mundy [ 06/Nov/07 03:47 AM ]
How about the latest component in trunk? I was comparing this to an earlier version and it seems that revision didn't
make it to 1.0.2 - the newer trunk version resolves a couple of issues with line endings. If you could please re-check
with that version we may be able to resolve this lingering issue.
Comment by Stanislav Malyshev [ 06/Nov/07 03:43 PM ]
Yes, trunk sends the mail correctly.
Comment by Simon Mundy [ 06/Nov/07 05:28 PM ]
Resolved in trunk - will be released ASAP.
[ZF-1933] SMTP transport adds extra EOL characters for many MTAs
Created: 11/Sep/07 Updated: 23/Jan/08 Resolved: 11/Sep/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.0, 1.0.1
Fix Version/s:          1.0.2

Type:                   Bug                                 Priority:              Major
Reporter:               Matthew Weier O'Phinney             Assignee:              Matthew Weier O'Phinney
Resolution:             Fixed                               Votes:                 0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
Zend_Mail_Transport_Smtp uses the EOL character "\r\n". Unfortunately, with some servers such as Exchange, this
causes the headers to have extraneous EOL characters, effectively mangling them. Solution is to set
Zend_Mail_Transport_Smtp::EOL to simply "\n"




Comments
Comment by Matthew Weier O'Phinney [ 11/Sep/07 02:43 PM ]
Patch applied to trunk in revision 6298; waiting for feedback before committing to release branch.
Comment by Matthew Weier O'Phinney [ 11/Sep/07 03:33 PM ]
Reporter indicates that the issue is resolved.
Comment by Darby Felton [ 18/Sep/07 12:07 PM ]
Also fixes 1.1.0
Comment by Wil Sinclair [ 23/Jan/08 06:28 PM ]
Updating Fix Version to follow issue tracker conventions.
[ZF-1925] Corrupted messages Created: 09/Sep/07                        Updated: 23/Jan/08 Resolved: 18/Sep/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.1
Fix Version/s:          1.0.2

Type:                   Bug                               Priority:                 Major
Reporter:               Raul Simiciuc                     Assignee:                 Nico Edtinger
Resolution:             Fixed                             Votes:                    0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
i think there are some problems with Zend_Mail. I`m using this code:

$transport = new Zend_Mail_Transport_Smtp($config->mail->server, $config-
>mail->config->toArray());
Zend_Mail::setDefaultTransport($transport);

$mail = new Zend_Mail('utf8');
$mail->setBodyText('line1
line2
line3
text text text
lin5');
$mail->setBodyHtml('
<html>
<body>
Message <b>bold</b><br/>
new line
</body>
</html>
');
$mail->setFrom('somebody@example.com', 'Some Sender');
$mail->addTo('someone@somedomain.com', 'Some Recipient');
$mail->setSubject('TestSubject');
$mail->send();

the mail received looks like:
gmail:

Content-Transfer-Encoding: quoted-printable =0A=0A
=0AMessage bold
=0Anew line=0A
=0A=0A

Yahoo:

Content-Type: text/plain; charset="utf8"
Content-Transfer-Encoding: quoted-printable



line1=0Aline2 =0Aline3=0Atext text text=0Alin5


Content-Type: text/html; charset="utf8"

Content-Transfer-Encoding: quoted-printable



=0A<html>=0A<body>=0AMessage <b>bold</b><br/>=0Anew line=0A</body>=0A</htm=
l>=0A


Comments
Comment by Thomas Weidner [ 11/Sep/07 01:03 PM ]
Assigned to Nico
Comment by Marc Jakubowski [ 11/Sep/07 03:14 PM ]
Hi there,
I have a similar error. In the mail body every 60th to 75th (seems random) character is replaced with an equal sign
"=".
It´s a hard coded plain text body without special characters.
Comment by Raul Simiciuc [ 14/Sep/07 04:59 PM ]
seems to work now with the last release from svn...
Comment by Darby Felton [ 18/Sep/07 01:06 PM ]
Reducing priority to major
Comment by Raul Simiciuc [ 18/Sep/07 01:11 PM ]
i think you can close this issue. I understood that were some problems with Zend_Mime and now are resolved...
Zend_Mail is working fine now...
Comment by Nico Edtinger [ 18/Sep/07 04:03 PM ]
fixed by recent changes according to reporter
Comment by Markus Breyer [ 12/Nov/07 09:38 PM ]
Hi - I am still getting EXACTLY this problem - I am using Zend Framework 1.0.2, and I also got the latest Mail and
Mime from the nightly build dated 11/10. Interesting is this shows only in my web mail, not in MS Outlook which
shows it fine. Below is the problematic mail. Any ideas? What can I try to address this? Thanks.

Return-Path: <notify@gumbofish.com>
Received: from gate8.gate.sat.mlsrvr.com (gate8.gate.sat.mlsrvr.com [192.168.1.33])
by mail43a.mail.sat.mlsrvr.com (SMTP Server) with ESMTP id 8EB7F1B4002
for <mailbox@pofik.com>; Mon, 12 Nov 2007 22:13:29 -0500 (EST)
X-Virus-Scanned: OK
X-Spam-Flag: NO
X-Spam-Score: 2.402
X-Spam-Level: **
X-Spam-Status: No, score=2.402 tagged_above=-100 required=6
tests=[RDNS_NONE=0.1, REVDNS_1=1.801, REVDNS_2=0.501]
X-Originating-Ip: [65.23.129.25]
Received: from centos_pristine (unknown [65.23.129.25])
by gate8.gate.sat.mlsrvr.com (SMTP Server) with ESMTP id 11B855B83A3;
Mon, 12 Nov 2007 22:13:27 -0500 (EST)
Date: Mon, 12 Nov 2007 22:13:23 -0500
Message-Id: <200711130313.lAD3DM0G014706@centos_pristine>
To: "greatguru" <great_guru@pofik.com>, "greatguru" <greatguru@pofik.com>
From: "Account Change Notification" <notify@gumbofish.com>
Subject: Notice of change in your account settings
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Dear greatguru,=0A=0AThis is to let you know that your account settings ha=
ve been successfully changed as follows:=0A=0A Changed email address from=
greatguru@pofik.com to great_guru@pofik.com.=0A=0A
Comment by Wil Sinclair [ 23/Jan/08 06:28 PM ]
Updating Fix Version to follow issue tracker conventions.
[ZF-1900] Zend_Mail_Part - problems with headers Created: 31/Aug/07                                          Updated:
23/Jan/08 Resolved: 08/Sep/07
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.0.0
Fix Version/s:           1.0.2

Type:                    Bug                                    Priority:                 Major
Reporter:                Krzysztof Osetek                       Assignee:                 Nico Edtinger
Resolution:              Fixed                                  Votes:                    0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
I'm reciving lot of emails with mixed case headers. In Zend_Mail_Part there is a code that compare headers to find
sth like 'multipart/' , 'boundary' , it works fine when header are lower case, but not working at all with uppercase
headers.

For eg. in one message I've got that:
MULTIPART/MIXED; BOUNDARY="0-1804289383-1188485096=:24518

Detection of multipart message with Zend_Mail_Part::isMultipart() fails.

The solution was simple:
[code]
public function isMultipart()
{
try { $this->contentType = strtolower($this->contentType); return strpos(strtolower($this->contentType), 'multipart/')
=== 0; } catch(Zend_Mail_Exception $e) { return false; }
}

[/code]

Another problem I encountered was with subject - there should be autodetection/autodecoding of QuotedPrintable
encoding on accessing $mail->subject (and other headers).




Comments
Comment by Krzysztof Osetek [ 31/Aug/07 05:25 PM ]
the solution was not as simple as I thought. The following changes helps.
Its a quick fix - the problem still exist for multi case strings (for eg. upper case first notation 'Boundary')

[code]

public function isMultipart()
{
try { return strpos(strtolower($this->contentType), 'multipart/') === 0; } catch(Zend_Mail_Exception $e) { return false; }
}

protected function _cacheContent()
{
// caching content if we can't fetch parts
if ($this->_content === null && $this->_mail) { $this->_content = $this->_mail->getRawContent($this-
>_messageNum); }

if (!$this->isMultipart()) { return; }

// split content in parts
$boundary = Zend_Mime_Decode::splitContentType($this->contentType, 'boundary') ;
if (!$boundary) { $boundary = Zend_Mime_Decode::splitContentType($this->contentType, 'BOUNDARY') ; }
if (!$boundary) { throw new Zend_Mail_Exception('no boundary found in content type to split message'); }
echo "\tboundary:" . $boundary;
$parts = Zend_Mime_Decode::splitMessageStruct($this->_content, $boundary);
$counter = 1;
foreach ($parts as $part) { $this->_parts[$counter++] = new self(array('headers' => $part['header'], 'content' =>
$part['body'])); }
}

[/code]
Comment by Bill Karwin [ 31/Aug/07 06:20 PM ]
Assign to Nico.
Comment by Nico Edtinger [ 08/Sep/07 02:04 PM ]
The content-type problem has been fixed in (1.0.2 & 1.1.0)

all field/parameter names are now also lowercased (as are header names) and matched case-insensitive
Comment by Wil Sinclair [ 23/Jan/08 06:28 PM ]
Updating Fix Version to follow issue tracker conventions.
[ZF-1849] "Retrieve" is spelt as "Retrive" in the Zend_Mail_*_Pop3 Created:
14/Aug/07 Updated: 23/Jan/08 Resolved: 26/Aug/07
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       None
Fix Version/s:           1.0.2

Type:                    Coding Standards Violation            Priority:                Trivial
Reporter:                Brenton Alker                         Assignee:                Nico Edtinger
Resolution:              Fixed                                 Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

File Attachments:           Zend_Mail_Protocol_Pop3.php.diff               Zend_Mail_Storage_Pop3.php.diff

Description
In Zend_Mail_Protocol_Pop3, there is a (public) function named retrive.
This may be intentional this is not a spelling I am familiar with, and I believe it is supposed to be "retrieve".

The function is also called in Zend_Mail_Storage_Pop3.

I will attach Patches.




Comments
Comment by Brenton Alker [ 14/Aug/07 09:41 AM ]
Patches for;
Zend_Mail_Protocol_Pop3
Zend_Mail_Storage_Pop3
Comment by Darby Felton [ 14/Aug/07 12:12 PM ]
Assigning to     Matthew Weier O'Phinney to initiate issue review.
Comment by Wil Sinclair [ 23/Jan/08 06:28 PM ]
Updating Fix Version to follow issue tracker conventions.
[ZF-1846] New function: Zend_Mail_Part::getHeaderField() Created: 13/Aug/07
Updated: 23/Jan/08 Resolved: 26/Aug/07
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     1.0.1
Fix Version/s:         1.0.2

Type:                  Patch                              Priority:               Major
Reporter:              Willie Alberty                     Assignee:               Nico Edtinger
Resolution:            Fixed                              Votes:                  0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified


Description
This patch adds a new convenience function to Zend_Mail_Part for extracting header fields, eliminating the need to
manually parse headers. Examples:

// instead of:
$contentType = strtok($message->contentType, ';');

// use this:
$contentType = $message->getHeaderField('content-type');
$charSet = $message->getHeaderField('content-type', 'charset');
// get attachment filename
$fileName = $part->getHeaderField('content-disposition', 'filename');
Index: tests/Zend/Mail/MessageTest.php
===================================================================
--- tests/Zend/Mail/MessageTest.php    (revision 6075)
+++ tests/Zend/Mail/MessageTest.php    (working copy)
@@ -67,6 +67,41 @@
         $this->assertEquals($message->subject, 'multipart');
     }

+    public function testGetHeaderFieldSingle()
+    {
+        $message = new Zend_Mail_Message(array('file' => $this->_file));
+        $this->assertEquals($message->getHeaderField('subject'),
'multipart');
+    }
+
+    public function testGetHeaderFieldDefault()
+    {
+        $message = new Zend_Mail_Message(array('file' => $this->_file));
+        $this->assertEquals($message->getHeaderField('content-type'),
'multipart/alternative');
+    }
+
+    public function testGetHeaderFieldNamed()
+    {
+        $message = new Zend_Mail_Message(array('file' => $this->_file));
+        $this->assertEquals($message->getHeaderField('content-type',
'boundary'), 'crazy-multipart');
+    }
+
+    public function testGetHeaderFieldMissing()
+    {
+        $message = new Zend_Mail_Message(array('file' => $this->_file));
+        $this->assertNull($message->getHeaderField('content-type', 'foo'));
+    }
+
+    public function testGetHeaderFieldInvalid()
+    {
+        $message = new Zend_Mail_Message(array('file' => $this->_file));
+        try {
+            $message->getHeaderField('fake-header-name', 'foo');
+        } catch (Zend_Mail_Exception $e) {
+            return;
+        }
+        $this->fail('No exception thrown while requesting invalid field
name');
+    }
+
     public function testGetDecodedHeader()
     {
         $message = new Zend_Mail_Message(array('file' => $this->_file));
Index: library/Zend/Mail/Part.php
===================================================================
--- library/Zend/Mail/Part.php (revision 6075)
+++ library/Zend/Mail/Part.php (working copy)
@@ -317,6 +317,30 @@

         return $header;
     }
+
+    /**
+      * Get a specific field from a header.
+      *
+      * If the header occurs more than once, only the value from the first
header
+      * is returned.
+      *
+      * Throws a Zend_Mail_Exception if the requested header does not exist.
If
+      * the specific header field does not exist, returns null.
+      *
+      * @param string $headerName
+      * @param string $fieldName (optional) If empty or omitted, returns
the
+      *   value of the primary field (the first, unnamed field).
+      * @return string
+      * @throws Zend_Mail_Exception
+      */
+    public function getHeaderField($headerName, $fieldName = '')
+    {
+         $headers = $this->getHeader($headerName, 'array');
+         if (empty($fieldName)) {
+            $fieldName = '__ZEND__PRIMARY__FIELD__NAME__'; // use an
unlikely string
+        }
+        return Zend_Mime_Decode::splitHeaderField($headers[0], $fieldName,
'__ZEND__PRIMARY__FIELD__NAME__');
+    }


       /**


Comments
Comment by Willie Alberty [ 13/Aug/07 10:00 PM ]
Included tests in patch.
Comment by Thomas Weidner [ 14/Aug/07 12:18 AM ]
Assigned to Nico
Comment by Nico Edtinger [ 26/Aug/07 01:07 PM ]
The default name for the first part is the same as in splitHeaderField(): 0. It's already a very unlikely field name.
Comment by Wil Sinclair [ 23/Jan/08 06:28 PM ]
Updating Fix Version to follow issue tracker conventions.
[ZF-1829] Zend_Mail doesn't consistently provide a fluent interface Created:
08/Aug/07 Updated: 23/Jan/08 Resolved: 26/Aug/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      None
Fix Version/s:          1.0.2

Type:                   Bug                                 Priority:           Trivial
Reporter:               Nathan Wright                       Assignee:           Nico Edtinger
Resolution:             Fixed                               Votes:              0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
These Zend_Mail methods return void when the documentation claims they provide a fluent interface:

Zend_Mail::setMimeBoundary()
Zend_Mail::addHeader()




Comments
Comment by Thomas Weidner [ 08/Aug/07 09:23 AM ]
Assigned to Nico
Comment by Wil Sinclair [ 23/Jan/08 06:28 PM ]
Updating Fix Version to follow issue tracker conventions.
[ZF-1795] Corrupted Attachments Created: 01/Aug/07                         Updated: 13/Nov/08 Resolved: 06/Nov/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.0.0
Fix Version/s:           1.7.0

Type:                    Bug                                   Priority:            Major
Reporter:                Florian Hoenig                        Assignee:            Thomas Weidner
Resolution:              Fixed                                 Votes:               6
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
I am having troubled with attachments when sending to AT&T (Cingular) MM3 Email-to-MMS gateway via SMTP.
Unfortunately the gateway's software is a black box to me, but the result that it "removed corrupted mime part
image/jpeg".

$mail->createAttachment($data['image'], 'image/jpeg', Zend_Mime::DISPOSITION_INLINE,
Zend_Mime::ENCODING_BASE64, $message->id."-img.jpg");

$data['image'] is the result of imagejpeg().

All this works really well with PEAR::Mail. I have played around with changing line end characters and changing the
line length, but it does not solve anything.

Mail.app on Mac and Outlook on Windows can read the attachments, but when I save it from Exchange Webmail, it
seems a little corrupted too (maybe because that front-end is not that smart to correct errors.)

Something seems fishy in Zend_Mime or Zend_Mail_Smtp and I cannot figure it out.




Comments
Comment by Darby Felton [ 01/Aug/07 12:16 PM ]
Assigning to     Matthew Weier O'Phinney to initiate issue review.
Comment by Matthew Weier O'Phinney [ 16/Nov/07 03:06 PM ]
Assigning to Nico
Comment by C. Suermann [ 04/Dec/07 08:10 AM ]
The problem seems to occur not always but rather sporadically. Unfortunately I cannot say under which
circumstances the attachment gets corrupted. When I run the very same code several times, most of the times
everything works as expected, but sometimes the attachment is broken. Hope this helps.
Comment by Thomas Weidner [ 06/Nov/08 01:03 PM ]
Fixed with r12343.
Changed linelength to 72 to be compatible with other mailers.

Seems to be related to and .
Feel free to reopen if it is not fixed for your environment.
Comment by Wil Sinclair [ 13/Nov/08 02:10 PM ]
Changing issues in preparation for the 1.7.0 release.
[ZF-1794] Problem with fetching messeges via pop3 from SmarterMail
Created: 31/Jul/07 Updated: 23/Jan/08 Resolved: 01/Aug/07
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       1.0.0
Fix Version/s:           1.0.2

Type:                    Bug                                     Priority:               Major
Reporter:                Krzysztof Osetek                        Assignee:               Nico Edtinger
Resolution:              Fixed                                   Votes:                  0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
Zend_Mail_Storage_Pop3 is unable to fetch messeges from SmarterMail server.
I was trying to run script from my local machine and from production server (web server and mail server are running
on the same machine, but have different IP) and in both cases script stops afeter some time without error messege.

I've install WIreShark on my local machine. I've run my script and Thunderbird, and I saw that TB sends CAPA
header >capa(), but it didn't help. Next few attempts and I figured out that the problem is proably in TCP connections.

WireShark screenshots while running:
1. Zend_Mail_Storage_Pop3 - http://holy.celinternet.pl/pop3.png
2. Thunderbird - http://holy.celinternet.pl/tb.png




Comments
Comment by Nico Edtinger [ 01/Aug/07 07:35 AM ]
I installed SmarterMail and found a bug in the pop3 protocol code, but I had different symptoms (server didn't read
request), so I don't know if it fixes your problem. Could you replace
$result = @fputs($this->_socket, $request . "\n");
with
$result = @fputs($this->_socket, $request . "\r\n");
in Zend_Mail_Protocol_Pop3::sendRequest() and test again, please?

We don't send CAPA because it's not needed. POP3 is very liberal - you may send commands without knowing if the
server supports it, what we do with TOP (but only once). Some servers lie in their CAPA so it's better to just try.
Comment by Krzysztof Osetek [ 01/Aug/07 11:47 AM ]

I seems that little \r soleves problem      Should I write to SmarterMail support?
Comment by Nico Edtinger [ 01/Aug/07 06:46 PM ]
Thank you. It was all my fault. The RFC clearly states commands should be terminated by <CRLF> and I don't know
why I did this wrong. It's a luck there's a strict mail server     You'll find the fix in SVN and the next release.
Comment by Wil Sinclair [ 23/Jan/08 06:28 PM ]
Updating Fix Version to follow issue tracker conventions.
[ZF-1740] Uninitialized string offset in Protocol/Imap.php Created: 18/Jul/07
Updated: 23/Jan/08 Resolved: 20/Jul/07
Status:                    Resolved
Project:                   Zend Framework
Component/s:               Zend_Mail
Affects Version/s:         1.0.0
Fix Version/s:             1.0.1

Type:                      Bug                               Priority:              Minor
Reporter:                  Joris Aerts                       Assignee:              Nico Edtinger
Resolution:                Fixed                             Votes:                 0
Remaining Estimate: Not Specified
Time Spent:                Not Specified
Original Estimate:         Not Specified


Description
When I try to connect to my imap server I get this notice (added echo $line to _decodeLine function):

FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)
OK [PERMANENTFLAGS (\* \Draft \Answered \Flagged \Deleted \Seen)] Limited
1 EXISTS
0 RECENT
OK [UIDVALIDITY 1184773671] Ok
OK [MYRIGHTS "acdilrsw"] ACL

Notice: Uninitialized string offset: 0 in /var/www/dev/querido/library/Zend/Mail/Protocol/Imap.php on line 182

Notice: Uninitialized string offset: 0 in /var/www/dev/querido/library/Zend/Mail/Protocol/Imap.php on line 187

Notice: Uninitialized string offset: 0 in /var/www/dev/querido/library/Zend/Mail/Protocol/Imap.php on line 194

OK [READ-WRITE] Ok




Comments
Comment by Darby Felton [ 19/Jul/07 03:56 PM ]
Assigning to       Nico Edtinger to initiate issue review.
Comment by Nico Edtinger [ 20/Jul/07 08:27 PM ]
Thank you for your report. The problem is, that we're currently not handling the response text in squared brackets in
the parser. I don't know why IMAP doesn't use just parenthesis for the response text like everywhere else. Anyway,
the notice is gone.
Comment by Darby Felton [ 27/Jul/07 10:52 AM ]
Also fixes 1.1.0
Comment by Wil Sinclair [ 23/Jan/08 06:32 PM ]
Updating Fix Version to follow issue tracker conventions.
[ZF-1737] Zend_Mail_Transport example for multiple mails per
connection Created: 18/Jul/07 Updated: 21/Mar/08 Resolved: 18/Jan/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       None
Fix Version/s:           1.5.0

Type:                    Docs: Problem                      Priority:              Major
Reporter:                Nathan Wright                      Assignee:              Simon Mundy
Resolution:              Fixed                              Votes:                 0
Remaining Estimate: 4 hours
Time Spent:              Not Specified
Original Estimate:       4 hours

Issue Links:             Duplicate
                         is duplicated by    ZF-2155    Sending Multiple Mails per SMTP Conne...             Closed
Language:               English
Fix Version Priority: Nice to Have

Description
The example here doesn't work http://framework.zend.com/manual/en/zend.mail.multiple-emails.html

Zend_Mail_Transport_Smtp does not even have connect() or disconnect() methods!

The transport itself automatically creates a connection when sending the first email – it provides no mechanism for
doing so beforehand.

Perhaps the example should include something like the following:

$conn = new Zend_Mail_Protocol_Smtp($host, $port);
$conn->connect();

$tr = new Zend_Mail_Transport_Smtp;
$tr->setConnection($conn);


Comments
Comment by Darby Felton [ 19/Jul/07 03:59 PM ]
Assigning to     Matthew Weier O'Phinney to initiate issue review.
Comment by Matthew Weier O'Phinney [ 16/Nov/07 02:56 PM ]
Scheduling for 1.1.0
Comment by Wil Sinclair [ 15/Jan/08 05:30 PM ]
Simon, can you take this one?
Comment by Simon Mundy [ 18/Jan/08 09:16 PM ]
Commited to trunk - could please review at your earliest convenience?
[ZF-1736] Zend_Mail_Protocol_Exception does not extend
Zend_Mail_Exception Created: 18/Jul/07 Updated: 15/Dec/07 Resolved: 05/Nov/07
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       None
Fix Version/s:           1.0.2

Type:                    Bug                             Priority:             Trivial
Reporter:                Nathan Wright                   Assignee:             Simon Mundy
Resolution:              Fixed                           Votes:                0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Fix Version Priority: Nice to Have

Description
Zend_Mail_Protocol_Exception directly extends Zend_Exception, not Zend_Mail_Exception like it should.




Comments
Comment by Darby Felton [ 19/Jul/07 04:00 PM ]
Assigning to     Simon Mundy to initiate issue review.
[ZF-1688] Long header lines containing non-printable characters are
corrupted Created: 07/Jul/07 Updated: 12/Feb/09 Resolved: 18/Jan/09
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     1.0.0, 1.7.3
Fix Version/s:         1.7.5

Type:                  Bug                                 Priority:             Critical
Reporter:              Willy Schott                        Assignee:             Benjamin Eberlei
Resolution:            Fixed                               Votes:                37
Remaining Estimate: 0 minutes
Time Spent:            8 hours, 30 minutes
Original Estimate:     Not Specified

File Attachments:          example_zf-1688.txt        MimeController.php
Issue Links:            Dependency
                        is dependecy of    ZF-4819    long mail subject bad encoding                Resolved
                        Duplicate
                        is duplicated by   ZF-3912    Incorrect encoding of 'subject' in Ch...      Resolved
                        is duplicated by   ZF-2532    Wrong encoded of the subject, if the ...      Resolved
                        is duplicated by   ZF-3865    Zend_Mail::_encodeHeader() encode inc...      Resolved
                        is duplicated by   ZF-3641    Zend_Mail: Wrong MIME header encoding         Resolved
                        is duplicated by   ZF-3588    Incorrect encoding of unicode subjects        Resolved
                        is duplicated by   ZF-1950    Correct method of encodeHeader "From"...      Resolved
                        Related
                        is related to      ZF-1950    Correct method of encodeHeader "From"...      Resolved
                        is related to      ZF-264     Quoted Printable Problems                     Resolved
Fix Version Priority: Must Have

Description
The following test case generates a mail with a non-readable subject line:

TestCase.php
<?php
require_once('Zend/Mail.php');
require_once('Zend/Mail/Transport/Smtp.php');
$mail = new Zend_Mail();
$mail->setSubject("Das ist eine Nachricht mit deutschen Ümläuten im Betreff
und einer absichtlich extralangen Betreffzeile, statt dessen ohne Text");
$mail->setBodyText('no text');
$mail->addTo('recipient@domain.com');
$mail->send(new Zend_Mail_Transport_Smtp());
?>
Result
=?iso-8859-
1?Q?Das=20ist=20eine=20Nachricht=20mit=20deutschen=20=DCml=E4uten=20im=20Betr
eff=20und=20einer=20abs=?ichtlich=20extralangen=20Betreffzeile,=20statt=20des
sen=20ohne=20Text?=
The reason of this bad behaviour is easily locateable: Zend_Mail::addSubject() first replaces line breaks by
question marks, then _encodeHeader() wraps lines longer than 74 chars only if they contain non-printable
characters, and afterwards _storeHeader() again replaces line breaks by question marks.

The problem applies to any type of header, not just the subject line.




Comments
Comment by Willy Schott [ 08/Jul/07 02:32 PM ]
After digging a bit, I'd like to suggest having a look into Pear::Mail_Mime, and how RFC2047 conformance is ensured
there. Using the same method for encoding header lines and body parts might not be sufficient since the
requirements are different.
Comment by Darby Felton [ 19/Jul/07 04:16 PM ]
Assigning to    Nico Edtinger to initiate issue review.
Comment by Sergey Belov [ 24/Jul/07 07:05 AM ]
I have such issue with long russian (non-printable) subjects too.
Is there any progress on fixing this bug? Hope, it will be fixed in 1.0.1.
Comment by Nico Edtinger [ 18/Sep/07 04:08 PM ]
Postponed because encoding will (most likely) be changed to iconv_mime_encode(), which should also fix this issue.
Comment by Nico Edtinger [ 18/Sep/07 04:09 PM ]
same fix
Comment by Jan Pieper [ 26/Nov/07 04:02 AM ]
Please look at my attached mail. The break in header causes (compare X-Original-Subject with Subject) that mails
with cyrillic characters can´t be decoded and will moved to junk.
Comment by Ota Mares [ 25/Mar/08 09:22 AM ]
Whats the current status of this bugfix?
It seems that this error still occurs in ZF 1.5. Long subject headlines will break the email encoding.

I am unsure if i should create a new issue or not.

http://www.nabble.com/ZF-1.5---Zend_Mail-and-long-subject-lines-td16097576s16154.html
Comment by Alexandre Lemaire [ 29/Jul/08 09:48 PM ]
I can confirm the same problem. Examining the headers, it appears that an extra newline is inserted into the header
when the line length exceeds the length to which ZF formats the message's horizontal distance.
Comment by Willy Schott [ 04/Sep/08 02:02 AM ]
A year has passed by since the fix was postponed. Now ZF 1.6 is out, and guess what? Still no fix.
For non-English people this issue is a blocker for using the Zend_Mail class (and most probably the Zend
Framework) at all.
Comment by Ota Mares [ 04/Sep/08 02:12 AM ]
I have to agree at some points with Willy, this bugreport is a year old, one with the most votes and a big deal breaker
for most non-English users.
Pointing out the bug in the #zftalk.dev channel doesnt seem to have changed anything.

Somehow this is disappointing.
Comment by Alexandre Lemaire [ 04/Sep/08 02:04 PM ]
Yes it is indeed disappointing, not only to users who are non-English, but moreso to people who develop with ZF, that
want to use Zend_Mail in a product that targets non-English audiences. If I were to commit some time to fixing this,
are we able to submit patches to the ZF project?
Comment by Wil Sinclair [ 04/Sep/08 03:33 PM ]
Nico, what is your current take on this issue? It has a lot of votes, so I think we should address it ASAP.

,Wil
Comment by Ota Mares [ 12/Sep/08 06:17 AM ]
Still nothing ...
Comment by Alexandre Lemaire [ 12/Sep/08 11:00 AM ]

There is some kind comical relief in this though        We seemingly can't 'communicate' with the guy who wrote
Zend_Mail!
Comment by Ota Mares [ 12/Sep/08 11:15 AM ]
Seems so, lets see if i can bring up the time to fix this, but i do not think so.
Comment by Alexandre Lemaire [ 12/Sep/08 11:30 AM ]
We could write our own! Zend_Mail_More! I think though, that a proper solution would lie in separating headers from
the body before any kind of decoding takes place. I offered to dedicate some company time to fixing this (we're
currently using imap as a fallback to solve this) since a contained solution would be nice; I just want some guarantee
that it will not be work-wasted. Our time, as is everyone's, is expensive.
Comment by Alexandre Lemaire [ 29/Sep/08 10:35 AM ]
Some reliable alternatives then:

1. the very old html_mime_mail class found here:
http://www.phpguru.org/static/mime.mail.html

2. The PHP IMAP implementations.
http://php.net/IMAP

3. MailParse
http://pear.php.net/package/mailparse

Zend Mail is simply not fit for production with this fatal flaw
Comment by Lukas Smith [ 07/Oct/08 01:12 AM ]
I am starting to notice a pattern with bugs I encounter in ZF:

          bug is already reported a year ago
          various solutions are proposed in the bug report
          a lot of people are suffering
          new ZF releases add all sorts of candy, but fail to address the open bugs


Comment by Frédéric Blanc [ 10/Oct/08 12:37 AM ]
Hello,

If this can help some of you, for my part I set up the following solution:

<?php

class My_Mail extends Zend_Mail {

public function __construct() { parent::__construct(); }

/**
         Sets the subject of the message
          *
         @param string $subject
         @return Zend_Mail Provides fluent interface
         @throws Zend_Mail_Exception
          */
          public function setSubject($subject)

          Unknown macro: { Zend_Debug}

          }

I know that this code is vulnerable in security but the subjects are hard-written within the application.
Do not use this if your subject is set by user in form.

It works for me waiting for a better solution.

Bests Regards,
Comment by Frédéric Blanc [ 10/Oct/08 02:56 AM ]
I'm sorry the code is bad formatted, I try again with 'code' option.

<?php

class My_Mail extends Zend_Mail {

        public function __construct() {
            parent::__construct();
        }

        /**
          * Sets the subject of the message
          *
          * @param    string    $subject
          * @return Zend_Mail Provides fluent interface
          * @throws Zend_Mail_Exception
          */
        public function setSubject($subject)
        {
             if ($this->_subject === null) {
                 $subject = strtr($subject,"\r\n\t",'???');
                 $this->_subject = $subject;
                 $this->_storeHeader('Subject', $this->_subject);
             } else {
                 /**
                   * @see Zend_Mail_Exception
                   */
                 require_once 'Zend/Mail/Exception.php';
                 throw new Zend_Mail_Exception('Subject set twice');
             }
             return $this;
        }
}

Bests regards
Comment by Thorsten Suckow-Homberg [ 10/Oct/08 04:17 AM ]
From RFC 1522:

RFC1522
While there is no limit to the length of a multiple-line header
field, each line of a header field that contains one or more
encoded-words is limited to 76 characters.

Here's my take on this. Tested and seems to work fine. I had some problems when the subject only contains Umlauts
(such as a string with the length of 128 chars consisting of only "äüöß"), which threw an iconv-error (error-code 7),
but AFAIK this is reated to a bug in the iconv-extension.

Zend_Mail::_encodeHeader()
protected function _encodeHeader($value)
    {
        if (Zend_Mime::isPrintable($value)) {
            return $value;
        } else {

                    $mimePrefs = array(
                        'scheme'                          =>     'Q';
                        'input-charset'                   =>     $this->_charset;
                        'output-charset'                  =>     $this->_charset;
                        'line-length'                     =>     74;
                        'line-break-chars'                =>     "\n";
                    );

                    $value = iconv_mime_encode('DUMMY', $value, $mimePrefs);
                    $value = preg_replace("#^DUMMY\:\ #", "", $value);

                    return $value;
             }
      }

I hope this helps you guys until this bug is officially fixed.
Comment by Thorsten Suckow-Homberg [ 10/Oct/08 04:21 AM ]
You might want to replace the semicolons ( ; ) with commas ( , )

$mimePrefs = array(
                'scheme'                                  =>     'Q',
                'input-charset'                           =>     $this->_charset,
                'output-charset'                          =>     $this->_charset,
                'line-length'                             =>     74,
                'line-break-chars'                        =>     "\n"
            );
Comment by Frédéric Blanc [ 10/Oct/08 04:31 AM ]

Thanks a lot Thorsten, it works fine.
Comment by Yo-han [ 21/Nov/08 02:09 AM ]
The fix works great. Why isn't this patch done in release 1.7?? Cost me 2 freaking hours to find this page and solve
my problem.
Comment by Manylov Pavel [ 30/Nov/08 06:55 AM ]

And why bug-hunt day doesn't touch this?
//sorry for my english
Comment by Andrei Nikolov [ 12/Dec/08 05:52 AM ]
Unfortunatelly there is also a bug in iconv_mime_encode function, which makes the fix of Thorsten Suckow-Homberg
not reliable

http://bugs.php.net/bug.php?id=43314

and +1 for

"I am starting to notice a pattern with bugs I encounter in ZF:
bug is already reported a year ago
various solutions are proposed in the bug report
a lot of people are suffering
new ZF releases add all sorts of candy, but fail to address the open bugs "
Comment by Ota Mares [ 09/Jan/09 11:01 AM ]
Okay, so i decided to investigated the issue and found the problem.
Its not Zend_Mail alone but also Zend_Mime and the problem consists of two bugs.

It is a bit complicated and not so easy to explain so this became a fairly long read.
Also please feel free to correct me or ask questions if something is incorret or unclear!

Ill start with the RFC definitions that will be usede for referencing when pointing out the issues and that help to
understand the problem a bit better.
And just for clarification a encoded header-value =?ISO-8859-1?Q?aaaaaa?= is referred as encoded-word.
The string "aaaaaa" is referred as encoded-text and "=?ISO-8859-1?Q?" and "?=" as delimiters, charset and
encoding, i refer to this three as DCE.

RFC definitions:

    1.   The key and value needs to be composed of printable US-ASCII characters, to accomplish this you have to
         encode the header value either with quoted-printable or base64.
    2.   An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text',
         and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters,
         multiple 'encoded-word's (separated by CRLF SPACE) may be used.
    3.   While there is no limit to the length of a multiple-line header field, each line of a header field that contains
         one or more 'encoded-word's is limited to 76 characters. It doesnt have to be exactly 76 chars long but
         should be about that length, some chars more or less dont hurt.
    4.   The 'encoded-text' may not be continued in the next 'encoded-word'.
    5.   Each value MUST represent an integral number of characters. A multi-octet character may not be split
         across adjacent 'encoded-word's.

Phew, in words that everyone understand this means:

    1.   Take the Header-line, encode its value.
    2.   Calculate how long a line would be when it includes the current DCE.
    3.   Split the encoded-value to chunks with a newline at the calculated length WITHOUT breaking an encoded-
         char.
    4.   Place the DCE at the start and end of every line.
    5.   ???
    6.   PROFIT!

Lets take the following example subject:
This is än germän multiline sübject with randöm ümläuts.

After doing all four steps from above the header value should look like this (i used the method
mb_encode_mimeheader for this result):
This is =?UTF-8?Q?=C3=A4n=20germ=C3=A4n=20multiline=20s=C3=BCbject=20with?=
=?UTF-8?Q?=20rand=C3=B6m=20=C3=BCml=C3=A4uts=2E?=

This is how it looks like after the string has been encoded with Zend_Mime::encodeQuotedPrintable, notice the length
and the missing space at the start of the second line which is required by point 2 of the definition list. The string gets
splitted into to big chunks because the method does not take into account the DCE length.
This is =C3=A4n germ=C3=A4n multiline s=C3=BCbject with rand=C3=B6m =C3=BC=
ml=C3=A4uts.

And this is the final result after Zend_Mail::_encodeHeader has done its job.
=?UTF-
8?Q?This=20is=20=C3=A4n=20germ=C3=A4n=20multiline=20s=C3=BCbject=20with=20rand=C3=B6m=20=C3=BC
=
ml=C3=A4uts.?=

Besides the not so tragical error of the length, you will see that the DCE is missing at the end of the first line (?=) and
the start of the second ( =?UTF-8?Q?)!
As also stated above all encoded-words need to be incased by the delimiters, charset and encoding syntax, this also
means encoded-words on new lines! _encodeHeader simply concats the corresponding DCE at the start and end of
the string. This would be the first major problem.
A not-so-good solution would be to replace every newline char with the DCE and a newline to get the desired result.
When using an iso charset this could work but not with utf8 or so called multibytechars and here comes the second
issue into play.

When looking at the Zend_Mime code you will see that the code for splitting only checks if it found an equalsign, if
yes it starts a newline.
Now take a look at the first umlaut we have, the "ä" that got encoded into "=C3=A4" because it consists of two bytes,
now imagine that umlaut would start exactly at the 73 position of a string, Zend_Mime would break the char apart
....=C3= \n A4 and thus breaking our encoded string, resulting in a borked email.
This is the second major issue because point 5 from above states that a multi-octet char may not be splited accross
adjacent encoded-words.

Lets recap the errors:

    1.   When an encoded value gets splitted onto mulitple lines the DCE params are missing.
    2.   Zend_Mime::encodeQuotedPrintable is not multibyte compatible.
    3.   Zend_Mime is not build for encoding email headers!

It would take alof of effort to fix both the issues but i think its possible. It definitively would need an own encoding
method which is build for mail header encoding.

A pass-by solution, as long as the iconv method is broken, would be to use the much better mbstring methods.
Please note that you need to explicitly activate the mbstring extension! This is the replace method we use at work,
right now:

_encodeHeader
protected function _encodeHeader($value)
{
     if (!Zend_Mime::isPrintable($value)) {
         $value = mb_encode_mimeheader($value, $this->_charset, 'Q', "\n",
74);
     }

      return $value;
}
To be honest i encourage everyone to use the above method because there can be other issues with Zend_Mime
and the way email headers get encoded. Also note that Zend_Mime works perfectly fine for the body encoding!

I really hope i explained the issue so we can start to discuss further steps.
Comment by Ota Mares [ 09/Jan/09 11:04 AM ]
Awww F*CK, why cant you edit your own posts?

The above posted version is not the one i wanted to post, it includes some spelling errors and stuff. So please bear
with me.
Comment by Ota Mares [ 09/Jan/09 11:17 AM ]
sigh I also noticed the stupid replacement of newlines and tabs in most of the set* methods with question marks.
I would suggest to replace the three question marks at the start of _encodeHeader with one space.

Oh and the RFCs i used for everyone who is interested into them
http://tools.ietf.org/html/rfc5322
http://tools.ietf.org/html/rfc2047
Comment by twk [ 10/Jan/09 10:01 PM ]
mb_encode_mimeheader works fine with Ota's example.
I also need a base64 encodingScheme so the Zend_Mime should be something like this.

iconv_mime_encode trick by Thorsten also works, but it will return the shorter lines
since it also counts 'DUMMY:' as the line length.

I don't think there is a good solution with Zend_Mime::encode, since the '?', ' ', '_' replacement
will overflow the line length. We need to extend Zend_Mime::encode.

I hope the following code can help you.

Mime.php
protected static $_encodingScheme = Zend_Mime::ENCODING_QUOTEDPRINTABLE;

public static function setDefaultEncodingScheme($encodingScheme)
{
        // should check here if quotedprintable or base64?
        self::$_encodingScheme = $encodingScheme;
}
public static function getDefaultEncodingScheme()
{
        return self::$_encodingScheme;
}

protected function _encodeHeader($value)
{
  if (Zend_Mime::isPrintable($value)) {
      return $value;
  } else {
      $encodingScheme = self::getDefaultEncodingScheme();
      $schemeChar = $encodingScheme == Zend_Mime::ENCODING_BASE64 ? 'B' :
'Q';

      if (function_exists('mb_encode_mimeheader')) {
          $encodedValue = mb_encode_mimeheader($s, $this->_charset,
$schemeChar);
      } else if (function_exists('iconv_mime_encode')) {
          // shorter but no problem
          $s = iconv_mime_encode('X', $s, array(
               'scheme'           => $schemeChar,
               'output-charset'   => $this->_charset,
               'line-break-chars' => "\r\n ",
          ));
          $s = preg_replace("#^X\:\ #", "", $s);
      } else {
          $prefix = '=?' . $this->_charset . '?' . $schemeChar . '?';
          $suffix = '?=';
          $lineLength = Zend_Mime::LINELENGTH - strlen($prefix) -
strlen($suffix);
          $lineEndChar = Zend_Mime::LINEEND;
          if ($encodingScheme == Zend_Mime::ENCODING_BASE64) {
               $encodedValue = Zend_Mime::encodeBase64($value, $encodeScheme,
$lineLength, $lineEndChar);
          } else ($encodeScheme == Zend_Mime::ENCODING_QUOTEDPRINTABLE) {
               $encodedValue = Zend_Mime::encodeQuotedPrintable($value,
$encodeScheme, $lineLength, $lineEndChar);
               // FIXME This replacement may exceeds the max linelength!
Maybe Zend_Mime::encode should have the additional parameters to set the
replace character set
               $quotedValue = str_replace(array('?', ' ', '_'), array('=3F',
'=20', '=5F'), $quotedValue);
          } else {
               throw new Zend_Mail_Exception('Unsupported encoding scheme "' .
$encodingScheme '"');
          }
          $quotedValue = str_replace($lineEndChar, $suffix . "\r\n " .
$prefix, $quotedValue);
          $encodedValue = $prefix . $quotedValue . $suffix;
      }

          return $encodedValue;
    }
}
Comment by Satoru Yoshida [ 10/Jan/09 10:05 PM ]
Hello, Ota Mares.

mb_encode_mimeheader needs mbstring extension is loaded.

I usually use the extension for treating Japanese.
But I do not know Europians and other peoples use the extension.

Do you know?
If there is no problem that the mbstring extension will be required, I will try to fix this issue.
Comment by Ota Mares [ 11/Jan/09 06:09 AM ]
Twk's method would be a nice solution if there wouldnt be the problems with the iconv or zend_mime method. (Btw.
why the hell do you people use preg_replace for removing the first x chars, use substr instead.)


Satoru, i cannot speak for all europeans      but most hosting servers have it activated and still its pretty easy to
install. Anyway by default the extension is not loaded!
Currently we are in a kind of dilemma, because iconv_mime_encode has a serious bug that results in broken mime
headers if a unspecified string length is reached.
See the link above from Andrei Nikolov, i wouldnt use that method until its fixed.
Zend_Mime is not build for email header encoding and the mbstring extension needs to be present.

To create a fix that would be extension indepentend you need to rewrite parts of zend_mail mainly removing the, to
me unexplainable, replacement of newlines with question marks (i would change that anyway) and as stated above
create a new encoding method for email headers. The second part would be the hardest, mainly because you need
to study all the rfc documents and need to apply the rules for email mime headers.
Comment by Satoru Yoshida [ 11/Jan/09 10:02 AM ]
Solved in SVN r13598

I will be happy if you evaluate this fix.
I do not copy to release-1.7 branch now.
Comment by Satoru Yoshida [ 11/Jan/09 05:39 PM ]
Additional change in SVN r13602.

Adds _filterOther() function instead of strtr("\r\n\t", '???') .
Comment by Ota Mares [ 12/Jan/09 01:46 AM ]
I will evaluate the fix during the course of this day.
Comment by Ota Mares [ 12/Jan/09 08:07 AM ]

Overall i like the changes, you also fixed some other bugs i wanted to report/look into.

Still i suggest to temporarly remove the iconv and zend_mail code parts and make zend_mail mbstring dependant
until the specific problems/bugs are fixed.
The iconv method has a very frustrating bug that can cause more harm then good and zend_mime will break the
encoded string when utf8 is used, both problems where stated more then once in the comments.

I found out that you should set the internal encoding of mb before using the mb_encode_mimeheader method, else
you will get some weird results from the method. (This is also stated in the PHP documentation). And i interpreted the
documentation wrong, the fourth param "indent" is not the overall linelength but then length of the header key, its
optional so i would remove it.

protected function _encodeHeader($value)
{
    if (!Zend_Mime::isPrintable($value)) {
        // pick the encoding to use. quoted-printable or base64
        $encoding = ($this->_encodingOfHeaders ===
Zend_Mime::ENCODING_QUOTEDPRINTABLE) ? 'Q' : 'B';

        // set mb internal encoding, this should be the same encoding as used
for mb_encode_mimeheader
        mb_internal_encoding($this->_charset);

        $value = mb_encode_mimeheader($value, $this->_charset, $encoding,
Zend_Mime::LINEEND);
    }

      return $value;
}
Comment by Ota Mares [ 12/Jan/09 08:20 AM ]
Oh and could you please change all "encodingofHeaders" instances to "headerEncoding", the former is just wrong :x
Comment by twk [ 12/Jan/09 06:24 PM ]
Yoshida-san, thanks for commiting.

Ota,
iconv_ issue (http://bugs.php.net/bug.php?id=43314 ) has a status "No Feedback". It would be a reason the problem
iss not fixed for a long time.
If you know the reproduceable input/output value pair with the latest php release build, could you please add them
there?

mb_internal_encoding is necessary and probably you need to rollback the current value.

Unable to find source-code formatter for language: php. Available languages are: javascript, sql, xhtml, actionscript,
none, html, xml, java
$current_internal_encoding = mb_internal_encoding();
mb_internal_encoding($this->_charset);
$value = mb_encode_mimeheader($value, $this->_charset, $encoding,
Zend_Mime::LINEEND);
mb_internal_encoding($current_internal_encoding);
Comment by Satoru Yoshida [ 13/Jan/09 08:24 AM ]
Additional commit in SVN r13612.

Hi, Ota Mares, thank You for evaluating.

At first, I find the 'Q' encoding causes error in the iconv_mime_encode function .
So I will check return value of the function.

At second, I add mb_internal_encoding() function.

At third, I remove forth parameter from mb_encode_mimeheader() function.

At last , I change the _encodingOfHeaders to _headerEncoding .

Thanks Your points!

Hi, twk, thank Your proposed logics.

I add as following.
$formerEncoding = mb_internal_encoding() .

They help me a lot!
Comment by Benjamin Eberlei [ 13/Jan/09 09:19 AM ]
Bug has been reopened as mbstring is not allowed to be used for this fix.

I have therefore added two new functions to Zend_Mime which encode Mime Headers correctly. I have added unitt-
tests to both Zend_Mail and Zend_Mime testsuites for this functionality and commited the fixes into the SVN repo.

Before i close this bug again, please re-check that the fixes are working for you please.
Comment by Satoru Yoshida [ 13/Jan/09 01:36 PM ]
Hi , Benjamin.
I find the lineLength parameter of encodeQuotedPrintableHeader() takes no effect .


encodeBase64Header is OK, thank you.
Comment by Benjamin Eberlei [ 13/Jan/09 02:27 PM ]
Hello Saturo,

i have added a testcase (testLineLengthInQuotedPrintableHeaderEncoding()) to Zend_MimeTest which checks for
the lineLength parameter.

Could you add your test-case that produces the failure?

But: There is one case, when no line-break will ocour at the given linelength: When the complete line has only
encoded chars (non US-ascii), because in this case the algorithm doesn't know where to cut.
Comment by Satoru Yoshida [ 14/Jan/09 04:41 AM ]
Hi, Benjamin.
I attach code for reproduce.

The code contains 4 patterns.

B-1. Zend_Mime::encodeBase64Header
Q-1. Zend_Mime::encodeQuotedPrintableHeader
B-2. Base64 by mb_encode_mimeheader
Q-2. QuotedPrintable by mb_encode_mimeheader

Results of the B-1 and B-2 are almost equal, but the Q-1 differs from the Q-2.
The difference is the result of Q-1 contains no linefeeds.

For example,
Result of the Q-1:
=?UTF-
8?Q?=E3=81=84=E3=82=8D=E3=81=AF=E3=81=AB=E3=81=BB=E3=81=B8=E3=81=A8=E3=81=A1=E3=82=8A=E
3=81=AC=E3=82=8B=E3=82=92=E3=82=8F=E3=81=8B=E3=82=88=E3=81=9F=E3=82=8C=E3=81=9D=E3=81=A4
=E3=81=AD=E3=81=AA=E3=82=89=E3=82=80?=

Result of the Q-2
=?UTF-8?Q?=E3=81=84=E3=82=8D=E3=81=AF=E3=81=AB=E3=81=BB=E3=81=B8=E3=81=A8?=
=?UTF-8?Q?=E3=81=A1=E3=82=8A=E3=81=AC=E3=82=8B=E3=82=92=E3=82=8F=E3=81=8B?=
=?UTF-8?Q?=E3=82=88=E3=81=9F=E3=82=8C=E3=81=9D=E3=81=A4=E3=81=AD=E3=81=AA?=
=?UTF-8?Q?=E3=82=89=E3=82=80?=

I hope it will help for you.
Comment by Satoru Yoshida [ 14/Jan/09 07:53 AM ]
Hi, Benjamin.
I take some fix in encodeBase64Header() function in SVN r13625, and I think this issue seems to be solved.

I think I have better to use base64 encoding more than quoted printable encoding in the case of my last comment.

Because If header value contains only multibyte characters, it causes no new line,
but the new line may destroy multibyte characters where is acrossed between former line and next line.
Comment by Benjamin Eberlei [ 14/Jan/09 03:17 PM ]
you are correct, i guess base64 encoding is the way to go on multibyte characters.

i have made another commit to this issue, breaking only at space and at sentence ending characters such as .!: and
so on. This is to support clients that produce a space when words are broken between lines.
Comment by Benjamin Eberlei [ 18/Jan/09 10:26 AM ]
Since i got no complaints about the fix i am resolving issue, will be included in next minor release 1.8
Comment by Satoru Yoshida [ 30/Jan/09 09:11 PM ]
I copied to 1.7 branch at SVN r13886.
Comment by Satoru Yoshida [ 02/Feb/09 06:19 PM ]
Sorry, not in 1.7.4. I think it will be released in next minor or major.
Comment by Benjamin Eberlei [ 12/Feb/09 03:36 PM ]
This will be in 1.7.5
[ZF-1626] Add methods for removing or replacing headers Created: 25/Jun/07
Updated: 03/Jan/09 Resolved: 03/Jan/09
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.0 RC3, 1.7.2
Fix Version/s:          1.7.3

Type:                   New Feature                          Priority:                Minor
Reporter:               Nico Edtinger                        Assignee:                Satoru Yoshida
Resolution:             Fixed                                Votes:                   1
Remaining Estimate: 0 minutes
Time Spent:             1 hour, 30 minutes
Original Estimate:      Not Specified

Issue Links:            Dependency
                        is dependecy of         ZF-3689   Recycle a Zend_Mail object and allow ...            Resolved
                        Duplicate
                        is duplicated by        ZF-3377   clear Recipients function                           Resolved
Fix Version Priority: Nice to Have

Description
[reported by tim weyand http://www.nabble.com/Zend_Mail---Zend_Mail_Transport_Smtp-Problems-
tf3963833s16154.html]

Feature "Wish" :
Could "delTo", "delCc", "delBcc", "delSubject", "delFrom" methods be added
to Zend_Mail?




Comments
Comment by Bill Karwin [ 27/Jun/07 10:35 AM ]
Assigned to Nico.
Comment by Bill Karwin [ 28/Jun/07 08:13 PM ]
Marking fix version as unknown. Please set fix version when this issue is resolved.
Comment by Tim Weyand [ 03/Jul/07 06:43 AM ]
In my opinion, it should be possible to delete settings, which have been set by the script.

["delTo", "delCc", "delBcc" (name sugesstion)]

After an email was send, in most cases it is neccessary to clear the receipient list. Currently you can add "infinite"
receipients to your reseipient list, but you can not delete any.

I think most people wouldn't need to delete a specific email adress out of the To,Cc,Bcc list, so i would sugesst that
an delTo would delete alle receipients in the "To receipient list".

Alternatively an "delReceipientList" would be easier to implement, but was in the past declined
http://framework.zend.com/issues/browse/ZF-30 .
I wrote an class which extends Zend_Mail, in this class i implemented a "delReceipientList".

public function delReceipientList() {
$this->_to=array();
$this->_recipients=array();
if (isset($this->_headers['To'])) unset($this->_headers['To']);
if (isset($this->_headers['Cc'])) unset($this->_headers['Cc']);
if (isset($this->_headers['Bcc'])) unset($this->_headers['Bcc']);
}

[delFrom]
In some cases you change not only the receipient, but also the sender. This case is for example a greeting card, a
news article which you want to send a friend ...

Currently you can set the from header only ones, otherwise you get an exception. Which is actually good, but there
should be an method to delete the From Header.

Maybe something like this :

public function delFrom() {
if (!is_null($this->_from)) $this->_from=null;
if (isset($this->_headers['From'])) unset($this->_headers['From']);
}

[delSubject]
The same as the from header, you can only set the subject line ones - otherwise you get an exception. This is not
that important for myself, but for the purpose of completion it should be implemented as well.

Maybe something like this :

public function delSubject() {
if (!is_null($this->_subject)) $this->_subject=null;
if (isset($this->_headers["Subject"])) unset($this->_headers["Subject"]);
}

I hope this helps.

regards,
Tim
Comment by Satoru Yoshida [ 03/Jan/09 04:23 AM ]
Implemented in SVN r13499.

I added Following functions

_clearHeader($headerName)
clearRecipients()
clearFrom()
clearReturnPath()
clearSubject()
clearDate()
[ZF-1622] Safe-Mode Warning in Zend_Mail while sending mails with
mail() Created: 25/Jun/07 Updated: 05/Jul/07 Resolved: 25/Jun/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      1.0.0 RC3
Fix Version/s:          1.0.0

Type:                   Bug                                   Priority:               Minor
Reporter:               Nico Edtinger                         Assignee:               Nico Edtinger
Resolution:             Fixed                                 Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
[from Geoffroy http://framework.zend.com/wiki/display/ZFMLGEN/mail/34276]

I have an issue with the Zend_Mail due to Safe mode.
Is this a bug or am I doing something wrong?

$mail = new Zend_Mail();
$mail->setBodyText('Hello')
->setFrom('xxxx@mail.com', 'XX')
->addTo('xxxx@mail.com')
->setSubject('Welcome!')
->send();

Warning: mail() [function.mail]: SAFE MODE Restriction in effect. The fifth
parameter is disabled in SAFE MODE. in /lib/Zend/Mail/Transport/Sendmail.php
on line 91




Comments
Comment by Nico Edtinger [ 25/Jun/07 10:37 AM ]
The warning gets raised although the fifth parameter is null (it is null most of the time). I didn't remove the warning as
I can't, because the parameters could be important and the warning tells you what's wrong in safe-mode. But if the
parameters are null mail() is now called without this fifth function parameter.
[ZF-1393] Zend_Mail - 20.6. Attachments > false method addAttachment()
used Created: 16/May/07 Updated: 15/Jun/08 Resolved: 01/Jun/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      None
Fix Version/s:          1.0.0 RC2

Type:                   Docs: Problem                      Priority:               Major
Reporter:               Muhammed Al-Khoutani               Assignee:               Nico Edtinger
Resolution:             Fixed                              Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Language:               English

Description
The documentation of the Attachments in Zend_Mail is mainly about the addAttachment() method whereas it should
be the createAttachment() method.
If you look at addAttachment in Zend/Mail.php you'll see that the argument should be a Zend_Mime_Part object.

public function addAttachment(Zend_Mime_Part $attachment)

{ $this->addPart($attachment); $this->hasAttachments = true; return $this; }

But the documentation says that it should a binary string "$mail->addAttachment($myImage, 'image/gif',
Zend_Mime::DISPOSITION_INLINE, Zend_Mime::ENCODING_8BIT);". These arguments match to the
createAttachment() method and therefore this should be used instead of the addAttachment() in the documentation.

public function createAttachment($body,
$mimeType = Zend_Mime::TYPE_OCTETSTREAM,
$disposition = Zend_Mime::DISPOSITION_ATTACHMENT,
$encoding = Zend_Mime::ENCODING_BASE64,
$filename = null)

{ $mp = new Zend_Mime_Part($body); $mp->encoding = $encoding; $mp->type = $mimeType; $mp->disposition =
$disposition; $mp->filename = $filename; $this->addAttachment($mp); return $mp; }

Comments
Comment by Bill Karwin [ 23/May/07 10:06 AM ]
Assigning to Nico.
Comment by Nico Edtinger [ 01/Jun/07 01:33 PM ]
Thanks for the report. The method got renamed for the fluent interface, doc is now correct.
Comment by Wil Sinclair [ 15/Jun/08 09:20 PM ]
Updating to comply with new IT component conventions.
[ZF-1377] Microsoft ESMTP responds with 220 instead of 250 to RSET
Created: 14/May/07 Updated: 05/Jul/07 Resolved: 14/May/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.9.3
Fix Version/s:          1.0.0 RC1

Type:                   Bug                                 Priority:          Minor
Reporter:               Nico Edtinger                       Assignee:          Nico Edtinger
Resolution:             Fixed                               Votes:             0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
As reported by Rafael Hengles:

I had a problem sending mails through a Microsoft ESMTP server, and I
discovered that on the RSET command, it returned 220 instead of the expected
by ZF, 250. I hacked it to "$this->_expect(array(250,220));" and now it
works. Anybody knows a better solution or why does this happen?
[ZF-1252] Imap: delete message Created: 12/Apr/07                       Updated: 05/Jul/07 Resolved: 17/Apr/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.9.2
Fix Version/s:          0.9.3

Type:                   Bug                                 Priority:                Major
Reporter:               Alexander Adam                      Assignee:                Nico Edtinger
Resolution:             Fixed                               Votes:                   0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
Sorry for my bad english:

At the moment i had to write a simple mailclient who communitate with an IMAP-Server. So i want to delete some
messages. But in the method removeMessage (Zend_Mail_Storage_Imap) you can find:

// TODO: real remove
        return false;
//        $this->_protocol->delete($id);

so i searched for a way to delete messages. i found out that i can set the deleted flag an than call the imap-command
"EXPUNGE". So i extended the class with this method:

/**
  * Excecutes EXPUNGE Command:
  *
  * The EXPUNGE command permanently removes all messages that have the
  * \Deleted flag set from the currently selected mailbox.
  * (RFC 3501)
  *
  */
public function expunge() {
         $this->_protocol->requestAndResponse('EXPUNGE',array(),true);
}

does this help? or is it planed to complete the mail classes?




Comments
Comment by Bill Karwin [ 17/Apr/07 07:20 PM ]
Assign to Nico.
Comment by Nico Edtinger [ 17/Apr/07 08:10 PM ]
Sorry for the inconvenience. removeMessage() and noop() are now both implemented.
Comment by Alexander Adam [ 18/Apr/07 03:03 AM ]
thanks, it works fine
[ZF-1236] timeout in Zend/Mime.php Created: 10/Apr/07                             Updated: 05/Jul/07 Resolved: 18/Apr/07
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail, Zend_Mime
Affects Version/s:       0.9.2
Fix Version/s:           0.9.3

Type:                    Bug                                   Priority:                    Major
Reporter:                Till Klampaeckel                      Assignee:                    Simon Mundy
Resolution:              Fixed                                 Votes:                       1
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
Fatal error: Maximum execution time of 30 seconds exceeded in
/foo/library/Zend/Mime.php on line 151

We get this when we try to send email using Zend_Mail_Transport_Smtp. All settings are verified, e.g. the mail server
works (and I can connect from the shell on the same server), settings (username, password) are correct,
allow_url_open is "On" and so on.

I think this was recently introduced either with 0.9.1 or 0.9.2 as I recall this working.

Here is the code I use to send email.

$cfg = array(
                                      'auth'            =>   'plain',
                                      'username'        =>   'foo',
                                      'password'        =>   'bar',
                                      'port'            =>   25,
                   );
                   $transport = new Zend_Mail_Transport_Smtp('mail.server', $cfg);
                   $mail->send($transport);

Happy to provide more feedback and code if necessary.




Comments
Comment by Simon Mundy [ 12/Apr/07 06:07 PM ]
Does this happen with all messages or only some? Can you provide a little more detail on how you construct a
message, along with a message body that you know that fails?
Comment by Till Klampaeckel [ 13/Apr/07 05:08 AM ]
It happens with all messages, here is how I get $mail:

$mail = new Zend_Mail();
$mail->setSubject('Neuer Kommentar');

$message         ='Es gibt einen neuen Kommentar auf Ihrer Homepage.';
$message .="\n\n";
$message .='Klicken Sie auf den folgenden Link, um zu dem Kommentar zu
gelangen:';
$message .="\n\n";
$message .=$comment_url;
$message.= "\n\n";
$message.= "-- \nmail robot";

$mail->setBodyText($message);
$mail->setFrom('noreply@mydomain.de', 'Mail Robot);
$mail->addTo($to_email, $to_name);

This is weird though, because the exact same code works in production. I was always thinking that this is a
connectivity issue with the mailserver but I can not trace the problem. As I said in my initial report, the server is
working and reachable from this web server. No connectivity issues what-so-ever.

Obviously all variables (such as $to_email, $to_name, $comment_url, ...) are set.

Thanks for looking into it!
Comment by Simon Mundy [ 18/Apr/07 08:22 PM ]
Resolved in trunk -r 4539
[ZF-1199] Call to undefined method
Zend_Mail_Transport_Smtp::connect() Created: 04/Apr/07                           Updated: 05/Jul/07 Resolved: 04/Apr/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.9.1
Fix Version/s:          None

Type:                   Bug                                Priority:              Major
Reporter:               Viktor Haffke                      Assignee:              Simon Mundy
Resolution:             Not an Issue                       Votes:                 0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
Windows XP
PHP 5.2.1

I get the following error message :

Call to undefined method Zend_Mail_Transport_Smtp::connect() in...

....
$mail = new Zend_Mail();
$tr = new Zend_Mail_Transport_Smtp($smtp_server);
Zend_Mail::setDefaultTransport($tr);
$mail->setMimeBoundary('=_' . md5(microtime(1)) .$mailbox_name);
$tr->connect();
....


Comments
Comment by Simon Mundy [ 04/Apr/07 08:18 AM ]
Hi Viktor

The example you show doesn't need to have the 'connect()' method - the transport class takes care of
opening/closing the connection internally and does not need to be set by the developer. Remove that line and you'll
be able to send mail as expected.
Comment by Viktor Haffke [ 04/Apr/07 08:49 AM ]
Hi Simon

This is described about in reference guide 20.3 Sending Multiple Mails and should be corrected.
[ZF-1193] Failure in Zend_Mail_MessageTest::testMultipleHeader() Created:
03/Apr/07 Updated: 05/Jul/07 Resolved: 17/Apr/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.9.1
Fix Version/s:          0.9.3

Type:                   Unit Tests: Problem              Priority:    Major
Reporter:               Bill Karwin                      Assignee:    Nico Edtinger
Resolution:             Fixed                            Votes:       0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
PHPUnit 3.0.0
PHP 5.2.0
Windows XP sp2
Xdebug 2.0.0RC1

Output of phpunit includes:

Zend_MailTest
  ..I..........

   Zend Framework - Zend_Mail
    Zend_Mail_MessageTest
    ..........F................

Failure messages include: (I have replaced control-M with ^M below)

25) testMultipleHeader(Zend_Mail_MessageTest)
Failed asserting that <text> is equal to <text>.
expected string <test
test2
multipart>
difference      <     xxxxxxxxxxxxxxxx??>
got string      <test^M
test2^M
multipart>
C:\zf\tests\Zend\Mail\MessageTest.php:136
[ZF-1189] Mime.php encodeQuotedPrintable - does not encode
whitespace to '=20' - heavy spamassassin penalty Created: 03/Apr/07 Updated: 05/Jul/07
Resolved: 01/Jun/07
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       0.9.0
Fix Version/s:           1.0.0 RC2

Type:                    Bug                                   Priority:         Major
Reporter:                Garth Gillespie                       Assignee:         Nico Edtinger
Resolution:              Fixed                                 Votes:            2
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
While checking email scores coming through spamassassin I noticed that the 'BAD_ENC_HEADER' rule was being
triggered - which refers to whitespace in mime encoded headers a violation of rfc 2047.

I added another str_replace line and the error went away and the spamassassin points assigned to the email dropped
almost 2 points.

patch is below. likely there is a more elegant way to do it.

$out = '';
$str = str_replace('=', '=3D', $str);
+ $str = str_replace(' ', '=20', $str);
$str = str_replace(self::$qpKeys, self::$qpReplaceValues, $str);

// Split encoded text into separate lines




Comments
Comment by Nico Edtinger [ 01/Jun/07 03:33 PM ]
Thanks for your report. The bug wasn't in encodeQuotedPrintable as it doesn't return encoded-words, but in
Zend_Mail::_encodeHeader(). Spaces are now encoded as well.
[ZF-1127] Test failures in Zend_Mail Created: 23/Mar/07                        Updated: 05/Jul/07 Resolved: 23/Mar/07
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       0.9.1
Fix Version/s:           0.9.1

Type:                    Unit Tests: Problem                 Priority:                Major
Reporter:                Bill Karwin                         Assignee:                Nico Edtinger
Resolution:              Fixed                               Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
PHP 5.2.1 on Cygwin

4) testSleepWakeRemoved(Zend_Mail_MboxTest)
no exception while waking with non readable file
/cygdrive/c/gavin/home/src/zftmp/tests/Zend/Mail/MboxTest.php:294
/cygdrive/c/gavin/home/src/zftmp/tests/AllTests.php:42
/cygdrive/c/gavin/home/src/zftmp/tests/AllTests.php:58

5) testNotReadableFolder(Zend_Mail_MboxFolderTest)
no exception while loading invalid dir with subfolder not readable
/cygdrive/c/gavin/home/src/zftmp/tests/Zend/Mail/MboxFolderTest.php:354
/cygdrive/c/gavin/home/src/zftmp/tests/AllTests.php:42
/cygdrive/c/gavin/home/src/zftmp/tests/AllTests.php:58


Comments
Comment by Nico Edtinger [ 23/Mar/07 09:08 PM ]
These tests should be skipped on Windows. It's also strange that cygwin is still able to read the files after a chmod 0.
The problem is it's necessary to make the file unreadable without removing it to test for a fopen error.

Bill could you tell me what you get with this script:
<?php
echo PHP_OS;
echo php_uname();
?>

Currently I'm using the PHP_OS check I found in http://php.net/php_uname . Maybe it's better to check for
'Windows' in the result of php_uname(). It works with Windows XP (without cygwin).
Comment by Nico Edtinger [ 23/Mar/07 10:03 PM ]
Ok forget my question. I'm now stat()ing the file after the chmod(). Windows returns 0444, for readonly, which is the
only supported flag. Cygwin should to the same.

I'm closing the bug, but please test again with Cygwin. I set the version to 0.9.1 - guess that's your target with such a
high priority
[ZF-1073] Zend_Mail Unit Tests failing Created: 17/Mar/07          Updated: 05/Jul/07 Resolved: 18/Mar/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.9.0
Fix Version/s:          0.9.1

Type:                   Unit Tests: Problem            Priority:     Major
Reporter:               Sebastian Nohn                 Assignee:     Simon Mundy
Resolution:             Fixed                          Votes:        0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
3) testZf928ToAndBccHeadersShouldNotMix(Zend_MailTest)
From: "" <info@onlime.ch>
Bcc: <first.bcc@email.com>,
<second.bcc@email.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Failed asserting that <string:> contains "to.address@email.com".
/home/sebastian/Work/ZendFramework/tests/Zend/MailTest.php:457




Comments
Comment by Bill Karwin [ 19/Mar/07 11:39 AM ]
Changing fix version to 0.9.1.
[ZF-1053] Zend_Mail_Transport_Smtp does not include Zend_Loader
Created: 14/Mar/07 Updated: 05/Jul/07 Resolved: 14/Mar/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.9.0
Fix Version/s:          0.9.0

Type:                   Bug                                 Priority:          Blocker
Reporter:               Simon Mundy                         Assignee:          Simon Mundy
Resolution:             Fixed                               Votes:             0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
From an email on 15th March, 2007 by Olivier Sirven:-

There is a fatal error in Zend_Mail_Transport_Smtp:
PHP Fatal error: Class 'Zend_Loader' not found
in /home/httpd/phpinclude/ZendFramework/Zend/Mail/Transport/Smtp.php on line
175

To be more specific I use Zend_Mail in a very simple script which does not
make use of Zend_Loader so I think Zend_Mail_Transport_Smtp should always
includes it
[ZF-1041] Zend_Mail splits up words in email body Created: 12/Mar/07                                  Updated:
18/Sep/09 Resolved: 18/Sep/09
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     0.8.0
Fix Version/s:         None

Type:                  Bug                                 Priority:               Major
Reporter:              Véronique M.                        Assignee:               Benjamin Eberlei
Resolution:            Not an Issue                        Votes:                  8
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified


Description
Using PHP Version 5.1.6-pl6-gentoo, I tried to use Zend_Mail to send a confirmation email upon a user registration. I
use HTML emails, and Zend's default transporter.
But sometimes spaces are inserted in the words, which would not be that bad if it didn't also sometimes break the link
that the user must click in order to activate his account.

Edit 2007/03/13: I'll add that this behaviour has occurred when viewing the sent email in Gmail, and Mozilla
Thunderbird. So far, my tests using Hotmail and Yahoo Mail have produced intact emails. Something to do with how
the mail clients interprete the maximum line lengths, perhaps....

Here is some test code I made for an example:

<?
require_once('Zend.php');

function __autoload($class_name) {
   Zend::loadClass($class_name);
}

define('SITE_NAME', 'MySite');
$email = 'v.marchand@gmail.com';
$username = 'vero';
$fullName = 'Vero. M.';
$url = 'http://www.' . SITE_NAME .
'.com/Inscription/Confirmer/key/7b2836967a0829a13c4c910683c82038e582afac';

$body = "
<html>
    <head>
        <style>
            body { font-family: Arial, Helvetica; font-size: 13px; }
        </style>
    </head>
<body>

<p> Bonjour <b>" . $fullName . "</b>,</p>
<p>Merci de vous être enregistré avec <b>" . SITE_NAME . "</b>.</p>

<p>
Votre compte " . $username . " est présentement inactif. Pour être activé, il
doit d'abord être validé en deux étapes.<br />
Pour la première étape de validation votre compte, veuillez tout simplement
cliquer sur le URL ci-dessous (vous pouvez également le copier dans votre
navigateur):
</p>
<a href='" . $url . "'>" . $url . "</a>
<p>Une fois votre adresse email validée, votre compte sera revu par l'équipe
" . SITE_NAME . " et activé. </p>

<p>Merci!</p>

<p>L'Équipe " . SITE_NAME . "</p>

</body>
</html>
";

$mail = new Zend_Mail();
$mail->setFrom('v.marchand@gmail.com', SITE_NAME);
$mail->addTo($email, $fullName);
$mail->setSubject('Votre inscription à ' . SITE_NAME);
$mail->setBodyHtml($body);
$mail->send();
?>

Here is the email I received on Gmail. Note the broken link, both in display (the space) and in the actual href (after the
http:// )

         < body>

         Bonjour Vero. M.,

         Merci de vous être e nregistré avec MySite.

         Votre compte vero est pré sentement inactif. Pour être activé, il doit d'abord être validé e n deux
         étapes.
         Pour la première étape de validation votre co mpte, veuillez tout simplement cliquer sur le URL ci-
         dessous (vous pouvez également le copier dans votre navigateur):
         http://www.MySite.com/Inscription/Confirmer/key/7b2836967a0829a13 c4c910683c82038e582afac


         Une fois votre adresse email validée, v otre compte sera revu par l'équipe MySite et activé.

         Merc i!

         L'Équipe MySite

Here is the email content with the full headers, in case it helps:

         Delivered-To: v.marchand@gmail.com
         Received: by 10.114.25.12 with SMTP id 12cs11848way;
         Mon, 12 Mar 2007 08:19:35 -0700 (PDT)
         Received: by 10.90.104.14 with SMTP id b14mr4553398agc.1173712775222;
         Mon, 12 Mar 2007 08:19:35 -0700 (PDT)
         Return-Path: <apache@zeus.opale>
         Received: from zeus.opale (modemcable042.27-70-69.static.videotron.ca [69.70.27.42])
         by mx.google.com with ESMTP id i5si8402101nzi.2007.03.12.08.19.34;
         Mon, 12 Mar 2007 08:19:35 -0700 (PDT)
         Received-SPF: neutral (google.com: 69.70.27.42 is neither permitted nor denied by best guess
         record for domain of apache@zeus.opale)
         Received: by zeus.opale (Postfix, from userid 81)
         id 8097A105A7; Mon, 12 Mar 2007 11:19:34 -0400 (EDT)
         To: "Vero. M." <v.marchand@gmail.com>
         Subject: =?iso-8859-1?Q?Votre inscription =E0 MySite?=
         From: "MySite" <v.marchand@gmail.com>
         To: "Vero. M." <v.marchand@gmail.com>
         Content-Type: text/html; charset="iso-8859-1"
         Content-Transfer-Encoding: quoted-printable
         Content-Disposition: inline
         Message-Id: <20070312151934.8097A105A7@zeus.opale>
         Date: Mon, 12 Mar 2007 11:19:34 -0400 (EDT)

         =0A<html>=0A <head>=0A <style>=0A body

         Unknown macro: { font-family}
         =0A </style>=0A </head>=0A<=

         body>=0A=0A<p> Bonjour <b>Vero. M.</b>,</p>=0A=0A<p>Merci de vous =EAtre e=

         nregistr=E9 avec <b>MySite</b>.</p>=0A=0A<p>=0AVotre compte vero est pr=E9=

         sentement inactif. Pour =EAtre activ=E9, il doit d'abord =EAtre valid=E9 e=

         n deux =E9tapes.<br />=0APour la premi=E8re =E9tape de validation votre co=

         mpte, veuillez tout simplement cliquer sur le URL ci-dessous (vous pouvez=

         =E9galement le copier dans votre navigateur):=0A</p>=0A<a href=3D'http://=

         www.MySite.com/Inscription/Confirmer/key/7b2836967a0829a13c4c910683c82038e=

         582afac'>http://www.MySite.com/Inscription/Confirmer/key/7b2836967a0829a13=

         c4c910683c82038e582afac</a>=0A<p>Une fois votre adresse email valid=E9e, v=

         otre compte sera revu par l'=E9quipe MySite et activ=E9. </p>=0A=0A<p>Merc=

         i!</p>=0A=0A<p>L'=C9quipe MySite</p>=0A=0A</body>=0A</html>=0A

Any suggestions? Perhaps there is a method I should use or setting I should change, but I'm not sure what exactly.
Thanks for your help.

PS: also you might notice that the "to" recipient is there twice. I think this is a known bug, but I'm bringing it up here
too, because it's been slightly bothering me.
Comments
Comment by Véronique M. [ 13/Mar/07 12:20 PM ]
clarification
Comment by Simon Mundy [ 14/Mar/07 05:38 PM ]
Your example above looks like there are empty lines between each encoded line - is this how it is on your email
source or is that just the way JIRA is displaying it? If there's extra linespaces it may be throwing the mail clients you
mentioned.
Comment by Véronique M. [ 15/Mar/07 08:16 AM ]
Hello,
Thanks for responding. In the above example, the first block is the email as it appears on Gmail. The last block with
the full headers is the actual email source.
Note that the broken words match the end of lines (=) in the source. Such as the words "e nregistré", "pré
sentement", "votre co mpte", "Merc i", and of course the link.

It clearly has something to do with the maximum line length, but I'm not sure what I can do about it. Surely there is a
way to use Zend_Mail without words being split like that (especially if it breaks important links), but I haven't been
able to figure out how, so I reported it here.
Comment by Bill Karwin [ 15/Mar/07 01:54 PM ]
Assigning to Nico.
Comment by thing2b [ 19/Mar/07 07:18 PM ]
I will just confirm that this happens for me as well.
One thing that I will note is that this did not appear for me in any versions 0.7 and before.
It started occurring when I moved to version 0.8 and continues to do it in version 0.9
Comment by Simon Mundy [ 19/Mar/07 07:29 PM ]
thing2b and Veronique, can you also please confirm which MTA is installed on your machines? Is it Postfix, QMail or
Sendmail?

Could you also please send a test email to webmaster at peptolab dot com so I can see the source intact?
Comment by thing2b [ 19/Mar/07 07:54 PM ]
I have send a message to Simon Mundy and with the same code sent myself one.
Using version 0.9.0 of Zend Framework.
Sendmail is in my phpinfo().
Postfix, QMail and not in my phpinfo().

$mail = new Zend_Mail();
$mail->setBodyText('Simon Mundy [19/Mar/07 07:29 PM]
thing2b and Veronique, can you also please confirm which MTA is installed on
your machines? Is it Postfix, QMail or Sendmail?
Could you also please send a test email to webmaster at peptolab dot com so I
can see the source intact?
');
$mail->setFrom( 'test@example.com' );
$mail->setReturnPath( 'test@example.com' );
$mail->addTo('cencored@gmail.com', 'Cencored');
$mail->setSubject( '[#ZF-1041] Zend_Mail splits up words in email body - Zend
Framework Issue Tracker' );
$mail->send();

And the mail I received at gmail was:

Delivered-To: cencored@gmail.com
Received: by 10.100.111.13 with SMTP id j13cs581656anc;
        Mon, 19 Mar 2007 17:40:55 -0700 (PDT)
Received: by 10.35.41.12 with SMTP id t12mr11603001pyj.1174351255333;
        Mon, 19 Mar 2007 17:40:55 -0700 (PDT)
Return-Path: <test@example.com>
Received: from luke.cencored.com.au (luke.cencored.com.au [64.49.254.38])
        by mx.google.com with ESMTP id w67si69927pyg.2007.03.19.17.40.54;
        Mon, 19 Mar 2007 17:40:55 -0700 (PDT)
Received-SPF: neutral (google.com: 64.49.254.38 is neither permitted nor
denied by best guess record for domain of test@example.com)
Received: (qmail 30589 invoked by uid 80); 20 Mar 2007 11:40:53 +1100
Date: 20 Mar 2007 11:40:53 +1100
Message-ID: <20070320004053.30588.qmail@luke.cencored.com.au>
To: "cencored" <cencored@gmail.com>
Subject: [#ZF-1041] Zend_Mail splits up words in email body - Zend Framework
Issue Tracker
From: "" <test@example.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


Simon Mundy [19/Mar/07 07:29 PM]=0D=0Athing2b and Veronique, can you also=

 please confirm which MTA is installed on your machines? Is it Postfix, QM=

ail or Sendmail?=0D=0ACould you also please send a test email to webmaster=

 at peptolab dot com so I can see the source intact?=0D=0A

Shown on screen through gmail is:

Simon Mundy [19/Mar/07 07:29 PM]
thing2b and Veronique, can you also
 please confirm which MTA is installed on your machines? Is it Postfix, QM
ail or Sendmail?
Could you also please send a test email to webmaster
 at peptolab dot com so I can see the source intact?

Note the break in the word "QMail"
Comment by Véronique M. [ 20/Mar/07 08:16 AM ]
I have sent the same email, with the same code posted earlier (in my first post) but with a CC to Simon and "ZF-
1041" prefixing the mail subject.

The email shown in Gmail is the same as I posted before. I tried also with Thunderbird, same thing. On the other
hand, the email displayed fine in Yahoo. But I haven't been able to find a way to print the original source in Yahoo
mail, though.

According to our sysadmin, we use postfix 2.2.10.
Comment by thing2b [ 22/Mar/07 07:25 PM ]
I have found a few resources that may help in the solving of this bug. The website:
http://www.nabble.com/Zend_Mail-problem-with-special-chars-and-automatic-line-break-t3128214s16154.html
has an interesting note about something that sounds the same.

The problem was:
>   Second, a long line with a link gets an automatic line break in the
>   middle of the link which makes the link invalid. Also I would like to
>   add a couple of empty lines but Zend_Mail always gets rid of them. I
>   would rather prefer to handle the line breaks myself to prevent
>   Zend_Mail from splitting up words and links in the middle.

And the bug was stated as:


- Finally, the bug: When using the Zend_Mail default transport --
PHP's own mail() function (sendmail) -- all of the CRLF end-of-line
sequences that Zend_Mime::encodeQuotedPrintable() correctly generates
are silently duplicated in the resulting message body. This results
in the correct 'soft line break' to continue a line, followed by an
additional CRLF by itself which mail clients interpret as a genuine
line break.

And the temporary fix that I am thinking about using in the mean time is:


2. If you're only ever going to use the default sendmail transport
with Zend_Mail, you can change Zend_Mime::encodeQuotedPrintable() so
that it only generates a single LF end-of-line sequence which will
not be duplicated by PHP's mail() function (this is the solution
proposed by Kevin in ZF-264). Change line 74 of Zend_Mime from this:

     const LINEEND = "\r\n";

to this:

     const LINEEND = "\n";

This change will cause problems if you attempt to use the SMTP
transport because now the end-of-line sequence is wrong. Your
messages will likely be rejected at some point in the delivery chain.
Comment by Simon Mundy [ 24/Mar/07 04:55 AM ]
Why thankyou thing! (Couldn't resist)

Thanks for following up the bugs. Problem is, Zend_Db_Transport_Sendmail does use the default PHP lineending
instead of "\r\n". So UNIX defaults to "\n".

It's not an easy one to track insofar as we're seeing different results using the same MTA so I'd like to find some more
common threads before we start committing changes.

This bug is still a priority but a fix will only be on the way once we're 100% sure!

Cheers
Comment by Tony Brady [ 29/Mar/07 06:53 AM ]
I have the same problem using the Postfix MTA 2.2.10 on RHEL 4. My work-around for now is not to use the quoted-
printable encoding. This is easily done by extending the Zend_Mail class and has the advantage that you don't need
to edit the ZF files (e.g. Zend_Mime LINEEND work-around above). All you need to do is change the
$mp->encoding = Zend_Mime::ENCODING_QUOTEDPRINTABLE;

line in setBodyText() and setBodyHtml() methods. E.g. (based on ZF-0.7):

/**
  * Fix to Zend_Mail so that mail is not sent out with quoted printable
encoding
*/
class MyApp_Mail extends Zend_Mail
{

     /**
       * Sets the text body for the message.
       *
       * @param string $txt
       * @param string $charset
       * @return Zend_Mime_Part
     */
     public function setBodyText($txt, $charset=null)
     {
          if ($charset === null) {
              $charset = $this->_charset;
          }

           $mp = new Zend_Mime_Part($txt);
           $mp->encoding = Zend_Mime::ENCODING_8BIT;
           $mp->type = Zend_Mime::TYPE_TEXT;
           $mp->disposition = Zend_Mime::DISPOSITION_INLINE;
           $mp->charset = $charset;

           $this->_bodyText = $mp;
           return $mp;
     }

     /**
       * Sets the HTML body for the message
       *
       * @param string $html
       * @param string $charset
       * @return Zend_Mime_Part
       */
     public function setBodyHtml($html, $charset=null)
     {
          if ($charset === null) {
              $charset = $this->_charset;
          }

           $mp = new Zend_Mime_Part($html);
           $mp->encoding = Zend_Mime::ENCODING_8BIT;
           $mp->type = Zend_Mime::TYPE_HTML;
           $mp->disposition = Zend_Mime::DISPOSITION_INLINE;
           $mp->charset = $charset;

           $this->_bodyHtml = $mp;
           return $mp;
     }
}
Comment by Véronique M. [ 09/Apr/07 12:35 PM ]
For the record, I am using the workaround posted above and so far I have not had any problems.

Is there any update from the devteam about this? I wonder if there's any reason to use the quoted-printable encoding
instead of the 8bit one...
Comment by Nico Edtinger [ 01/Jun/07 02:48 PM ]
As Simon has written this bug is not easy to track down. Newlines are handled differently depending on the platform
and MTA. As Tony has written one workaround is a different encoding. With the fix to the encoding can be changed
with the third parameter in setBodyText() and setBodyHtml().
Comment by Benjamin Eberlei [ 11/Jan/09 01:18 AM ]
Since the bug does not depend on Zend_Mail, but on lower layers of Mail transport shouldn't the workaround
possiblity through the API just be documented and the bug be closed?
Comment by Véronique M. [ 20/Feb/09 11:23 AM ]
Sorry for the delay in responding. I have no problem with documenting the use of the third parameter and closing the
bug, myself.
Comment by Benjamin Eberlei [ 18/Sep/09 06:17 AM ]
Close as bug/problem in the lower MTA layers, which can be circumvented with using base64 instead of quoted
printable encoding.
[ZF-1033] Several unit test problems Created: 11/Mar/07                             Updated: 05/Jul/07 Resolved: 14/Mar/07
Status:                                 Resolved
Project:                                Zend Framework
Component/s:                            Zend_Db, Zend_Http_Client, Zend_Mail
Affects Version/s:                      0.8.0
Fix Version/s:                          0.9.0

Type:                                   Unit Tests: Problem             Priority:        Major
Reporter:                               Thomas Weidner                  Assignee:        Bill Karwin
Resolution:                             Fixed                           Votes:           0
Remaining Estimate: Not Specified
Time Spent:                             Not Specified
Original Estimate:                      Not Specified


 Description
Problems with Unit Tests within the following classes:

Zend_Db
Zend_Mail

Zend_Http_Client throws for all tests skipped, but it should be enough to test once per testsuite as done by
Zend_Db_Adapter.

Used SVN version 3867.
--------------------------
PHPUnit 3.1.0beta2 by Sebastian Bergmann.

Zend Framework
Zend Framework - Zend
Zend_AclTest
......................................
............

Zend Framework - Zend_Cache
Zend_Cache_FactoryTest
.....

Zend_Cache_CoreTest
.....................................

Zend_Cache_FileBackendTest
..............................

Zend_Cache_OutputFrontendTest
...

Zend_Cache_FunctionFrontendTest
.........

Zend_Cache_ClassFrontendTest
...........
Zend_Cache_FileFrontendTest
...........

Zend_Cache_PageFrontendTest
............

Zend_ConfigTest
..................

Zend Framework - Zend_Config
Zend_Config_IniTest
...............

Zend_Config_XmlTest
..........

Zend_Console_GetoptTest
.............................

Zend Framework - Zend_Controller
Zend_Controller_ActionTest
...................

Zend_Controller_Dispatcher_StandardTest
......................

Zend_Controller_FrontTest
.....................S............

Zend_Controller_Plugin_BrokerTest
..

Zend_Controller_Request_HttpTest
.....................................
....

Zend_Controller_Response_HttpTest
...............

Zend_Controller_Router_RouteTest
.....................................
....

Zend_Controller_Router_Route_ModuleTest
.....................

Zend_Controller_Router_Route_StaticTest
.........

Zend_Controller_Router_RewriteTest
.......................

Zend_DateTest
......................................
.....................................I
.

Zend Framework - Zend_Date_DateObject
Zend_Date_DateObjectTest
...................

Zend Framework - Zend_Db
Zend_Db_DbTest
..E......

Zend_Db_ProfilerTest
..

Zend_Db_Adapter_Skip_Db2Test
S

Zend_Db_Adapter_Skip_MysqliTest
S

Zend_Db_Adapter_Skip_OracleTest
S

Zend_Db_Adapter_Skip_Pdo_MssqlTest
S

Zend_Db_Adapter_Skip_Pdo_MysqlTest
S

Zend_Db_Adapter_Skip_Pdo_OciTest
S

Zend_Db_Adapter_Skip_Pdo_PgsqlTest
S

Zend_Db_Adapter_Skip_Pdo_SqliteTest
S

Zend_DebugTest
.

Zend Framework - Zend_Feed
Zend_Feed_ArrayAccessTest
....

Zend_Feed_AtomEntryOnlyTest
.

Zend_Feed_AtomPublishingTest
..

Zend_Feed_CountTest
.

Zend_Feed_ElementTest
..

Zend_Feed_ImportTest
.................

Zend_Feed_IteratorTest
....

Zend_FilterTest
..

Zend Framework - Zend_Filter
Zend_Filter_AlnumTest
.

Zend_Filter_AlphaTest
.

Zend_Filter_BaseNameTest
.

Zend_Filter_DigitsTest
.

Zend_Filter_DirTest
.

Zend_Filter_HtmlEntitiesTest
.....

Zend_Filter_IntTest
.

Zend_Filter_RealPathTest
..

Zend_Filter_StringToLowerTest
.

Zend_Filter_StringTrimTest
....

Zend_Filter_StripTagsTest
........

Zend Framework - Zend_Gdata
Zend_Gdata_GdataTest
......

Zend_Gdata_BaseTest
.........

Zend_Gdata_BloggerTest
........
Zend_Gdata_CalendarTest
.......

Zend_Gdata_CodeSearchTest
....

Zend_Gdata_DataTest
....

Zend_Gdata_SkipOnlineTest
S

Zend_Gdata_SkipClientLoginTest
S

Zend Framework - Zend
Zend_Http_ResponseTest
..........I........

Zend_Http_CookieTest
....................

Zend_Http_CookieJarTest
.................

Zend Framework - Zend
Zend_Http_Client_StaticTest
..............

Zend_Http_Client_SocketTest
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

Zend_Http_Client_SocketKeepaliveTest
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

Zend_Http_Client_TestAdapterTest
..........

Zend_Http_Client_ProxyAdapterTest
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

Zend_JsonTest
........................

Zend_LoaderTest
........

Zend_LocaleTest
........................

Zend Framework - Zend_Locale
Zend_Locale_DataTest
......

Zend_Locale_FormatTest
.................

Zend_MailTest
..I.......

Zend Framework - Zend_Mail
Zend_Mail_MessageTest
.................

Zend_Mail_InterfaceTest
..............

Zend_Mail_MboxTest
...................

Zend_Mail_MboxFolderTest
F....EEEEEEEEEEEE

Zend Framework - Zend_Measure
Zend_Measure_Cooking_VolumeTest
............................

Zend_Measure_Cooking_WeightTest
............................

Zend_Measure_Flow_MassTest
............................

Zend_Measure_Flow_MoleTest
............................

Zend_Measure_Flow_VolumeTest
............................

Zend_Measure_Viscosity_DynamicTest
............................

Zend_Measure_Viscosity_KinematicTest
............................

Zend_Measure_AccelerationTest
...........

Zend_Measure_AngleTest
............................

Zend_Measure_AreaTest
............................

Zend_Measure_BinaryTest
............................

Zend_Measure_CapacitanceTest
..........................
Zend_Measure_CurrentTest
..........................

Zend_Measure_DensityTest
............................

Zend_Measure_EnergyTest
............................

Zend_Measure_ForceTest
..........................

Zend_Measure_FrequencyTest
............................

Zend_Measure_IlluminationTest
..........................

Zend_Measure_LengthTest
............................

Zend_Measure_LightnessTest
..........................

Zend_Measure_NumberTest
.......

Zend_Measure_PowerTest
.............................

Zend_Measure_PressureTest
.............................

Zend_Measure_SpeedTest
............................

Zend_Measure_TemperatureTest
............................

Zend_Measure_TorqueTest
............................

Zend_Measure_VolumeTest
............................

Zend_Measure_WeightTest
............................

Zend_MimeTest
.....

Zend Framework - Zend_Mime
Zend_Mime_PartTest
...
Zend_Mime_MessageTest
.....

Zend Framework - Zend_Pdf
Zend Framework - Zend_Pdf_Element
Zend_Pdf_Element_ArrayTest
......

Zend_Pdf_Element_BooleanTest
....

Zend_Pdf_Element_DictionaryTest
........

Zend_Pdf_Element_NameTest
......

Zend_Pdf_Element_NullTest
...

Zend_Pdf_Element_NumericTest
.......

Zend_Pdf_Element_ObjectTest
..........

Zend Framework - Zend_Pdf_Element_Object
Zend_Pdf_Element_Object_StreamTest
...

Zend_Pdf_Element_StreamTest
......

Zend_Pdf_Element_StringTest
.....

Zend Framework - Zend_Pdf_Element_String
Zend_Pdf_Element_String_BinaryTest
......

Zend_RegistryTest
...............

Zend Framework - Zend_Rest
Zend_Rest_ServerTest
....................................

Zend_Rest_ClientTest
...........

Zend_Rest_ResultTest
.................

Zend Framework - Zend_Server
Zend_Server_ReflectionTest
....

Zend_Server_Reflection_ClassTest
......

Zend_Server_Reflection_FunctionTest
........

Zend_Server_Reflection_MethodTest
...

Zend_Server_Reflection_NodeTest
..........

Zend_Server_Reflection_ParameterTest
.....

Zend_Server_Reflection_PrototypeTest
....

Zend_Server_Reflection_ReturnValueTest
.....

Zend_UriTest
......

Zend Framework - Zend_Uri
Zend_Uri_HttpTest
................

Zend_ValidateTest
....

Zend Framework - Zend_Validate
Zend_Validate_AlnumTest
..

Zend_Validate_AlphaTest
..

Zend_Validate_BetweenTest
.....

Zend_Validate_CcnumTest
..

Zend_Validate_DateTest
..

Zend_Validate_FloatTest
..

Zend_Validate_EmailAddressTest
............
Zend_Validate_GreaterThanTest
...

Zend_Validate_HexTest
..

Zend_Validate_HostnameTest
.......

Zend_Validate_InArrayTest
....

Zend_Validate_IntTest
..

Zend_Validate_IpTest
..

Zend_Validate_LessThanTest
...

Zend_Validate_RegexTest
....

Zend_Validate_StringLengthTest
....

Zend_ViewTest
.................................

Zend_VersionTest
.

Zend Framework - Zend_XmlRpc
Zend_XmlRpc_ValueTest
.........................

Zend_XmlRpc_RequestTest
..........

Zend_XmlRpc_Request_HttpTest
...

Zend_XmlRpc_ResponseTest
........

Zend_XmlRpc_FaultTest
........

Zend_XmlRpc_ClientTest
.......................

Zend_XmlRpc_ServerTest
.........................
Zend_XmlRpc_Server_CacheTest
..

Zend_XmlRpc_Server_FaultTest
........

Time: 52 seconds

There were 13 errors:

1) testGetConnection(Zend_Db_DbTest)
Zend_Db_Adapter_Exception: The sqlite driver is not currently installed
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Db\Adapter\Abstract.php:119
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Db\DbTest.php:65

2) testChangeFolder(Zend_Mail_MboxFolderTest)
Zend_Mail_Storage_Exception: folder test.mbox not found
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:1
83
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:9
0
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Mail\MboxFolderTest.php:94

3) testChangeFolderUnselectable(Zend_Mail_MboxFolderTest)
Zend_Mail_Storage_Exception: folder test.mbox not found
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:1
83
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:9
0
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Mail\MboxFolderTest.php:106

4) testUnknownFolder(Zend_Mail_MboxFolderTest)
Zend_Mail_Storage_Exception: folder test.mbox not found
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:1
83
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:9
0
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Mail\MboxFolderTest.php:118

5) testGlobalName(Zend_Mail_MboxFolderTest)
Zend_Mail_Storage_Exception: folder test.mbox not found
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:1
83
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:9
0
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Mail\MboxFolderTest.php:130

6) testLocalName(Zend_Mail_MboxFolderTest)
Zend_Mail_Storage_Exception: folder test.mbox not found
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:1
83
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:9
0
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Mail\MboxFolderTest.php:141

7) testIterator(Zend_Mail_MboxFolderTest)
Zend_Mail_Storage_Exception: folder test.mbox not found
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:1
83
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:9
0
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Mail\MboxFolderTest.php:151

8) testKeyLocalName(Zend_Mail_MboxFolderTest)
Zend_Mail_Storage_Exception: folder test.mbox not found
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:1
83
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:9
0
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Mail\MboxFolderTest.php:173

9) testSelectable(Zend_Mail_MboxFolderTest)
Zend_Mail_Storage_Exception: folder test.mbox not found
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:1
83
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:9
0
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Mail\MboxFolderTest.php:195

10) testCount(Zend_Mail_MboxFolderTest)
Zend_Mail_Storage_Exception: folder test.mbox not found
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:1
83
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:9
0
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Mail\MboxFolderTest.php:206

11) testSize(Zend_Mail_MboxFolderTest)
Zend_Mail_Storage_Exception: folder test.mbox not found
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:1
83
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:9
0
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Mail\MboxFolderTest.php:218

12) testFetchHeader(Zend_Mail_MboxFolderTest)
Zend_Mail_Storage_Exception: folder test.mbox not found
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:1
83
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:9
0
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Mail\MboxFolderTest.php:231

13) testSleepWake(Zend_Mail_MboxFolderTest)
Zend_Mail_Storage_Exception: folder test.mbox not found
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:1
83
C:\Voxtronic\3rdParty\Zend Framework\library\Zend\Mail\Storage\Folder\Mbox.php:9
0
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Mail\MboxFolderTest.php:243
There was 1 failure:

1) testLoadOk(Zend_Mail_MboxFolderTest)
exception raised while loading mbox folder
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Mail\MboxFolderTest.php:42
There were 3 incomplete tests:
1) testTimesync(Zend_DateTest)
NTP timeserver not available.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\DateTest.php:4833

2) test100Continue(Zend_Http_ResponseTest)

C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\ResponseTest.php:132

3) testHeaderEncoding2(Zend_MailTest)
still working on cross-platform tests
There were 101 skipped tests:

1) testDispatch7(Zend_Controller_FrontTest)
Issues with $_GET in CLI interface prevents test from passing
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Controller\FrontTest.php:282

2) testDbAdapter(Zend_Db_Adapter_Skip_Db2Test)
Testing Zend_Db_Adapter_Db2 is not enabled in TestConfiguration.php
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Db\Adapter\SkipTests.php:39

3) testDbAdapter(Zend_Db_Adapter_Skip_MysqliTest)
Testing Zend_Db_Adapter_Mysqli is not enabled in TestConfiguration.php
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Db\Adapter\SkipTests.php:39

4) testDbAdapter(Zend_Db_Adapter_Skip_OracleTest)
Testing Zend_Db_Adapter_Oracle is not enabled in TestConfiguration.php
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Db\Adapter\SkipTests.php:39

5) testDbAdapter(Zend_Db_Adapter_Skip_Pdo_MssqlTest)
Testing Zend_Db_Adapter_Pdo_Mssql is not enabled in TestConfiguration.php
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Db\Adapter\SkipTests.php:39

6) testDbAdapter(Zend_Db_Adapter_Skip_Pdo_MysqlTest)
Testing Zend_Db_Adapter_Pdo_Mysql is not enabled in TestConfiguration.php
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Db\Adapter\SkipTests.php:39

7) testDbAdapter(Zend_Db_Adapter_Skip_Pdo_OciTest)
Testing Zend_Db_Adapter_Pdo_Oci is not enabled in TestConfiguration.php
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Db\Adapter\SkipTests.php:39

8) testDbAdapter(Zend_Db_Adapter_Skip_Pdo_PgsqlTest)
Testing Zend_Db_Adapter_Pdo_Pgsql is not enabled in TestConfiguration.php
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Db\Adapter\SkipTests.php:39

9) testDbAdapter(Zend_Db_Adapter_Skip_Pdo_SqliteTest)
Testing Zend_Db_Adapter_Pdo_Sqlite is not enabled in TestConfiguration.php
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Db\Adapter\SkipTests.php:39

10) testOnline(Zend_Gdata_SkipOnlineTest)
Zend_Gdata online tests are not enabled in TestConfiguration.php
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Gdata\SkipTests.php:36

11) testClientLogin(Zend_Gdata_SkipClientLoginTest)
Zend_Gdata authenticated tests are not enabled in TestConfiguration.php
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Gdata\SkipTests.php:49
12) testSimpleRequests(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

13) testGetLastRequest(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

14) testGetLastResponse(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

15) testGetLastResponseWhenNotStoring(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

16) testGetData(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

17) testDoubleGetParameter(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

18) testPostDataUrlEncoded(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

19) testPostDataMultipart(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

20) testRawPostData(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

21) testResetParameters(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

22) testParameterUnset(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

23) testHeadersSingle(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

24) testHeadersArray(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

25) testMultipleHeader(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

26) testRedirectDefault(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

27) testRedirectStrict(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

28) testMaxRedirectsExceeded(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

29) testAbsolutePathRedirect(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

30) testRelativePathRedirect(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

31) testHttpAuthBasic(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

32) testCancelAuth(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

33) testCookiesStringNoJar(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

34) testSetCookieObjectNoJar(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75
35) testSetCookieObjectArray(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

36) testSetCookieStringArray(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

37) testSetCookieObjectJar(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

38) testUploadRawData(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

39) testUploadLocalFile(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

40) testUploadNameWithSpecialChars(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

41) testStaticLargeFileDownload(Zend_Http_Client_SocketTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

42) testSimpleRequests(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

43) testGetLastRequest(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

44) testGetLastResponse(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

45) testGetLastResponseWhenNotStoring(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

46) testGetData(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

47) testDoubleGetParameter(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

48) testPostDataUrlEncoded(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

49) testPostDataMultipart(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

50) testRawPostData(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

51) testResetParameters(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

52) testParameterUnset(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

53) testHeadersSingle(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

54) testHeadersArray(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

55) testMultipleHeader(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

56) testRedirectDefault(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

57) testRedirectStrict(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75
58) testMaxRedirectsExceeded(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

59) testAbsolutePathRedirect(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

60) testRelativePathRedirect(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

61) testHttpAuthBasic(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

62) testCancelAuth(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

63) testCookiesStringNoJar(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

64) testSetCookieObjectNoJar(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

65) testSetCookieObjectArray(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

66) testSetCookieStringArray(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

67) testSetCookieObjectJar(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

68) testUploadRawData(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

69) testUploadLocalFile(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

70) testUploadNameWithSpecialChars(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

71) testStaticLargeFileDownload(Zend_Http_Client_SocketKeepaliveTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\SocketTest.php:75

72) testGetLastRequest(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

73) testSimpleRequests(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

74) testGetLastResponse(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

75) testGetLastResponseWhenNotStoring(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

76) testGetData(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

77) testDoubleGetParameter(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

78) testPostDataUrlEncoded(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

79) testPostDataMultipart(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

80) testRawPostData(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

81) testResetParameters(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

82) testParameterUnset(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

83) testHeadersSingle(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

84) testHeadersArray(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

85) testMultipleHeader(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

86) testRedirectDefault(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

87) testRedirectStrict(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

88) testMaxRedirectsExceeded(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

89) testAbsolutePathRedirect(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

90) testRelativePathRedirect(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

91) testHttpAuthBasic(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

92) testCancelAuth(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

93) testCookiesStringNoJar(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

94) testSetCookieObjectNoJar(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

95) testSetCookieObjectArray(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

96) testSetCookieStringArray(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

97) testSetCookieObjectJar(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

98) testUploadRawData(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76
99) testUploadLocalFile(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

100) testUploadNameWithSpecialChars(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

101) testStaticLargeFileDownload(Zend_Http_Client_ProxyAdapterTest)
Set to skip Zend_Http_Client dynamic tests. Please see TestConfiguration.php.dis
t if you want to enable dynamic tests.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Http\Client\ProxyAdapterTest.php
:76

FAILURES!
Tests: 2177, Failures: 1, Errors: 13, Incomplete: 3, Skipped: 101.

--------------------------
PHP Version 5.2.1
Windows XP
Standard Installation




Comments
Comment by Nico Edtinger [ 11/Mar/07 05:08 PM ]

the mbox part is done - i leave the status unchanged. last one switches off the light
Comment by Thomas Weidner [ 12/Mar/07 02:50 AM ]
Thanks Nico... Zend_Mail now works...
Waiting for the other problems
Comment by Bill Karwin [ 13/Mar/07 12:10 PM ]
Db test failures fixed in revision 3898.
Comment by Thomas Weidner [ 13/Mar/07 03:27 PM ]
Now an other failure is showing up:

1) testGetConnection(Zend_Db_DbTest)
Failed asserting that <string:The PDO extension is required for this adapter
but
 not loaded> is equal to <string:The sqlite driver is not currently
installed>.
C:\Voxtronic\3rdParty\Zend Framework\tests\Zend\Db\DbTest.php:72
Comment by Bill Karwin [ 13/Mar/07 04:00 PM ]
Thomas, you certainly have a nonstandard PHP environment!
You don't have PDO or Sqlite loaded, but you do have xmldom loaded.

I have added logic to the Db unit tests to handle the case where the base PDO extension is not loaded.
See revision 3908.
Comment by Bill Karwin [ 13/Mar/07 04:22 PM ]
I'm still not sure what issue you're seeing with Zend_Http_Client. It appears to be a number of tests that are
deliberately being skipped. I don't see any errors or failures. Can you comment more specifically what you think it is
doing wrong?
Comment by Thomas Weidner [ 13/Mar/07 05:13 PM ]
Standard Windows PHP 5.2.1 installation only with gettext extension enabled.
But it's ok for me if we know where the problem is related and have this somewhere noted
I think in future some other people could have the same problems.

Zend_Http_Client:
In my opinion the testbed should be skipped and not all 100 tests.
So we have 100 skipped tests for the complete Zend_Http_Client classes.
But 3 (one per class) should also do.

Why run all tests if they are skipped within the TestConfiguration...
Like the Zend_Db_Adapters... if the PDO is not loaded only one skip is thrown per Adapter.
This is what I would expect also from Zend_Http_Client.
Comment by Bill Karwin [ 13/Mar/07 06:08 PM ]

Good point. Yes, the number of skipped tests is large. I solved the problem in my environment by enabling them.

I have implemented the workaround to skip a whole testcase class, like I did for Zend_Db and Zend_Gdata.

Fixed in revision 3909.
Comment by Thomas Weidner [ 14/Mar/07 04:44 AM ]
Issue has completly been fixed.
Thankx
[ZF-993] Zend_Mail_Transport_Sendmail mail function return-path with
opiton -f Created: 01/Mar/07 Updated: 05/Jul/07 Resolved: 16/Mar/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.8.0
Fix Version/s:          0.9.0

Type:                   Improvement                        Priority:               Major
Reporter:               Falk Doering                       Assignee:               Simon Mundy
Resolution:             Fixed                              Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
I am using the Zend_Mail_Transport_Sendmail adapter to send e-mails. I set the return-path with
Zend_Mail::setReturnPath(), but the mailserver overrider the header with his own return-path. I must set the options
parameter from the php mail() function ('-f<emailaddress>') to work correctly. Can this set in the
Zend_Mail_Transport_Sendmail to?




Comments
Comment by Bill Karwin [ 01/Mar/07 04:16 PM ]
Assign to Nico.
Comment by Simon Mundy [ 16/Mar/07 03:23 AM ]
Documentation will be updated shortly
[ZF-989] Duplicate To: headers Created: 28/Feb/07                        Updated: 05/Jul/07 Resolved: 16/Mar/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.8.0
Fix Version/s:          0.9.0

Type:                   Bug                                  Priority:                 Minor
Reporter:               Alex Adriaanse                       Assignee:                 Simon Mundy
Resolution:             Fixed                                Votes:                    1
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

Issue Links:            Duplicate
                        duplicates      ZF-928    Zend_Mail mixes To: and Bcc: headers ...                    Resolved

Description
If I send an email with a single To: address using Zend_Mail_Transport_Sendmail it sends the same email twice.

This seems to be caused by duplicate To: headers. For instance, a sampling of the headers may look like this:

To: <alex@innovacomputing.com>
Subject: Subject goes here
From: "User" <alex@innovacomputing.com>
To: <alex@innovacomputing.com>
Content-Type: multipart/alternative; charset="iso-8859-1";
 boundary="=_6e1345cd6d0e8711c3affdf659433023"
MIME-Version: 1.0

I believe this is caused by the destination email address being supplied twice to mail(): as the first argument of mail(),
and as one of the headers in the fourth argument of mail().

I am seeing this problem with PHP 5.2.0.




Comments
Comment by Bill Karwin [ 01/Mar/07 04:16 PM ]
Assign to Nico.
Comment by Simon Mundy [ 16/Mar/07 03:29 AM ]
Resolved in trunk r4010
[ZF-980] Zend_Mail Should Allow Users to Specifiy MIME Part
Parameters Created: 26/Feb/07 Updated: 05/Jul/07 Resolved: 01/Jun/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.8.0
Fix Version/s:          1.0.0 RC2

Type:                   Improvement                        Priority:               Minor
Reporter:               Gregory Szorc                      Assignee:               Nico Edtinger
Resolution:             Fixed                              Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:            Accept_Mime_Part.diff      Encoding_Parameter.diff

Description
Zend_Mail::setBodyText() currently only allows a specific type of MIME part to be set. Users should be able to define
parameters for the MIME part. For example, users should be able to set the encoding to 7bit, instead of the default
QUOTEDPRINTABLE.

Perhaps setBodyText() should optionally accept an instance of Zend_Mime_Part?




Comments
Comment by Nico Edtinger [ 26/Feb/07 02:04 PM ]
But setBodyText() already returns the instance it creates. You could even use fluent interfaces to change the
encoding type:

$mail->setBodyText('your body')->encoding = Zend_Mime::ENCODING_7BIT;

Or is this to complicated?
Comment by Gregory Szorc [ 26/Feb/07 02:06 PM ]
Accept first parameter to setBodyText() to be instance of Zend_Mime_Part
Comment by Gregory Szorc [ 26/Feb/07 02:11 PM ]
This patch adds an $encoding parameter to setBodyText() that allows user to override the default encoding of
ENCODING_QUOTEDPRINTABLE
Comment by Gregory Szorc [ 26/Feb/07 08:33 PM ]
Nico, you are right. I don't know how I missed that.

The addition of an encoding parameter is simple, and might make the method more intuitive. After all, the only two
properties of Zend_Mime_Part that would ever need to be modified for setBodyText() are the encoding and charset.

Some documentation under getBodyText() reminding people that the variable is passed by reference might also go a
long way.
Comment by Bill Karwin [ 01/Mar/07 04:16 PM ]
Assign to Nico.
Comment by Nico Edtinger [ 01/Jun/07 02:31 PM ]
Encoding can be changed via the third parameter in setBodyText() and setBodyHtml().
[ZF-957] Fluent interface improvements to Zend_Mail Created: 23/Feb/07                                  Updated:
05/Jul/07 Resolved: 16/Mar/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.8.0
Fix Version/s:          0.9.0

Type:                   Improvement                       Priority:               Trivial
Reporter:               Shaun Rowe                        Assignee:               Simon Mundy
Resolution:             Duplicate                         Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
I believe that Zend_Mail could benefit from a couple fluent interface/method chaining improvements, most of the
setters and add methods could be updated. I'm suggesting the following are considered:

setSubject()
setReturnPath()
setMimeBoundary()
setFrom()
addTo()
addCc()
addBcc()
addHeader()

This was requested in and a patch uploaded but does not seem to be in the SVN trunk.

Thanks

Shaun




Comments
Comment by Bill Karwin [ 25/Feb/07 05:11 PM ]
Assigning to Matthew.
Comment by Simon Mundy [ 16/Mar/07 03:34 AM ]
Will be resolving so this issue is redundant.
[ZF-928] Zend_Mail mixes To: and Bcc: headers on multiple Bcc Created:
16/Feb/07 Updated: 05/Jul/07 Resolved: 16/Mar/07
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       0.8.0
Fix Version/s:           0.9.0

Type:                    Bug                                  Priority:                Major
Reporter:                Philip Iezzi                         Assignee:                Matthew Weier O'Phinney
Resolution:              Fixed                                Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

Issue Links:             Duplicate
                         is duplicated by            ZF-989        Duplicate To: headers                   Resolved

Description
Again, this is an issue that was previously reported to the fw-general list and is still not fixed in r3503. Sorry about not
reporting it earlier as an issue.
I think this is a major misbehavior of Zend_Mail and if possible should be fixed before the 0.8 release.

given the following code:

$mail = new Zend_Mail();
$mail->setSubject('my subject');
$mail->setBodyText('my body');
$mail->setFrom('info@onlime.ch');
$mail->addTo('to.address@email.com');
$mail->addBcc('first.bcc@email.com');
$mail->addBcc('second.bcc@email.com');
//print_r($mail);
$mail->send();

The print_r($mail) output before sending the mail looks fine:

[_headers:protected] => Array
        (
            [Subject] => Array
                (
                    [0] => my subject
                )

                   [From] => Array
                       (
                           [0] => "" <info@onlime.ch>
                           [append] => 1
                       )

                   [To] => Array
                       (
                               [0] => <to.address@email.com>
                               [append] => 1
                          )

                  [Bcc] => Array
                      (
                          [0] => <first.bcc@email.com>
                          [append] => 1
                          [1] => <second.bcc@email.com>
                      )

            )

The resulting email got the following messed up header:

To: <to.address@email.com> <second.bcc@email.com>

I neither received the mail on first.bcc@email.com nor on second.bcc@email.com




Comments
Comment by Matthew Weier O'Phinney [ 20/Feb/07 07:55 AM ]
I've done a little research on this. When using a generic transport (one that simply extends the abstract), everything
works perfectly – to and bcc addresses are reported with the correct headers. However, when I use a sendmail-type
transport, I get slightly different results than those reported, but equally bad: I have no To: header at all, only Bcc
headers. I'll resolve this issue shortly.
Comment by Matthew Weier O'Phinney [ 20/Feb/07 08:13 AM ]
Should be resolved in current SVN; please test. If you continue to experience issues, please provide detailed
information as to the transport, MTA, and OS used so we can better replicate the issue.
Comment by Philip Iezzi [ 20/Feb/07 05:05 PM ]
Now it does no longer mix To and Bcc addresses but we get double To: lines in our mail header:

...
To: <to.address@email.com>
Subject: my subject
From: "" <info@onlime.ch>
To: <to.address@email.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
...

The Bcc recipients correctly receive the email but all emails contain a doubled To:

Tested on PHP 5.2.1standard-mail() transport, Postfix 2.3.6 on a Debian Linux Etch box.
Comment by Philip Iezzi [ 16/Mar/07 05:33 AM ]
Resolved in trunk r4010
[ZF-927] Zend_Mail strips down empty newlines in body message Created:
16/Feb/07 Updated: 05/Jul/07 Resolved: 14/Mar/07
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       0.8.0
Fix Version/s:           0.9.0

Type:                    Bug                                  Priority:                Major
Reporter:                Philip Iezzi                         Assignee:                Matthew Weier O'Phinney
Resolution:              Fixed                                Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
I have posted this to the fw-general list before and it is still not fixed in r3503. Tested on PHP 5.2.0 and 5.2.1

Zend_Mail strips down empty newlines in the message body set by setBodyText():

$mail = new Zend_Mail();
$mail->setSubject('my subject');
$mail->setBodyText("my body\r\n\r\n...after two newlines");
$mail->setFrom('info@onlime.ch');
$mail->addTo('test@email.com');
// print_r($mail);
$mail->send();

A print_r($mail) before sending the mail looks correct:

...
      [_bodyText:protected] => Zend_Mime_Part Object
          (
              [type] => text/plain
              [encoding] => quoted-printable
              [id] =>
              [disposition] => inline
              [filename] =>
              [description] =>
              [charset] => iso-8859-1
              [boundary] =>
              [_content:protected] => my body

...after two newlines
            [_isStream:protected] =>
        )
...

In the resulting email the empty newline is cut down though and we get:

my body
...after two newlines


Comments
Comment by Simon Mundy [ 16/Feb/07 03:46 PM ]
What transport are you using? SMTP or the default?
Comment by Philip Iezzi [ 16/Feb/07 04:07 PM ]
I'm using default transport, mail gets send over the mail()-function in Zend_Mail_Transport_Sendmail::_sendMail() as
far as I know.
Same applies to issue ZF-928.
Comment by Philip Iezzi [ 16/Feb/07 04:09 PM ]
besides, I have tested it on both Win32 and Debian Linux under PHP 5.2.0 and 5.2.1
Comment by Matthew Weier O'Phinney [ 20/Feb/07 03:16 PM ]
I've committed a patch to Zend_Mime, Zend_Mime_Part, and Zend_Mime_Message that should correct the issue;
please test and confirm.
Comment by Philip Iezzi [ 20/Feb/07 04:47 PM ]
Sorry Matthew to disappoint you. Now it even seems to be worse.

"my body\r\n\r\n...after two newlines" on win32, result:

my body
...after two newlines

"my body\r\n\r\n...after two newlines" on linux, result:

my body



...after two newlines

4 newlines!, while the \r seems to get encoded to a weird character, source of email:

my body=0D
=0D
...after two newlines

"my body\n\n...after two newlines" on linux, result:

my body
...after two newlines
Comment by Simon Mundy [ 14/Mar/07 05:35 PM ]
Hi Phillip - has this been resolved for you with the more recent svn commits?
Comment by Philip Iezzi [ 14/Mar/07 05:43 PM ]
Yep! This seems to be resolved in the current trunk.
[ZF-925] Zend_Mail_Protocol_Abstract does not allow IP addresses or
localhost as mail host Created: 16/Feb/07 Updated: 05/Jul/07 Due: 16/Feb/07 Resolved: 16/Feb/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.8.0
Fix Version/s:          0.8.0

Type:                   Bug                                     Priority:           Critical
Reporter:               Simon Mundy                             Assignee:           Simon Mundy
Resolution:             Fixed                                   Votes:              0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
Originall posted by Olivier Sirven on the Zend Mailing List:-

Hi,

There is a fatal error in the constructor of Zend_Mail_Protocol_Abstract so
I think it would be nice to correct it before the release
Moreover, this constructor does not accept ip adresses or local name
which is not very useable....Here is the patch I use:

Index: Zend/Mail/Protocol/Abstract.php
===================================================================
— Zend/Mail/Protocol/Abstract.php (revision 3495)
+++ Zend/Mail/Protocol/Abstract.php (working copy)
@@ -128,11 +128,13 @@
public function __construct($host = '127.0.0.1', $port = null)
{
$this->_validHost = new Zend_Validate();

          $this->_validHost->addValidator(new Zend_Validate_Hostname());
           + $validor = new Zend_Validate_Hostname();
           + $validor->setAllow(Zend_Validate_Hostname::ALLOW_ALL);
           + $this->_validHost->addValidator($validor);

if (!$this->_validHost->isValid($host)) { require_once 'Zend/Mail/Protocol/Exception.php'; - throw new
Zend_Mail_Protocol_Exception(join(', ', $this->_validHost->getMessage())); + throw new
Zend_Mail_Protocol_Exception(join(', ', $this->_validHost->getMessages())); }




Comments
Comment by Simon Mundy [ 16/Feb/07 05:44 AM ]
Resolved in trunk (r3497)
[ZF-924] Zend_Mail Unit Tests failing Created: 16/Feb/07                         Updated: 05/Jul/07 Resolved: 03/Apr/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.8.0
Fix Version/s:          0.9.2

Type:                   Unit Tests: Problem                  Priority:               Major
Reporter:               Sebastian Nohn                       Assignee:               Nico Edtinger
Resolution:             Fixed                                Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
1) testHeaderEncoding(Zend_MailTest)
Failed asserting that <text> contains "=?iso-8859-
1?Q?"=E4=FC=F6=DF=C4=D6=DC"=20?=<testmail2@example.com>".
/home/sebastian/Work/ZendFramework/tests/Zend/MailTest.php:152

2) testHeaderEncoding2(Zend_MailTest)
Failed asserting that <text> contains "Cc: =?iso-8859-
1?Q?"=E4=FC=F6=DF=C4=D6=DC"=20?=<testmail3@example.com>".
/home/sebastian/Work/ZendFramework/tests/Zend/MailTest.php:184

3) testMultipartAlternative(Zend_MailTest)
Failed asserting that <boolean:false> is not equal to <null>.
/home/sebastian/Work/ZendFramework/tests/Zend/MailTest.php:220

4) testAttachment(Zend_MailTest)
Failed asserting that <boolean:false> is not equal to <null>.
/home/sebastian/Work/ZendFramework/tests/Zend/MailTest.php:270

5) testMultipartAlternativePlusAttachment(Zend_MailTest)
Failed asserting that <boolean:false> is not equal to <null>.
/home/sebastian/Work/ZendFramework/tests/Zend/MailTest.php:324

6) testDecodeMimeMessage(Zend_Mime_MessageTest)
Failed asserting that <string:application/octet-stream> is equal to <string:image/gif>.
/home/sebastian/Work/ZendFramework/tests/Zend/Mime/MessageTest.php:117

$ svn up
At revision 3491.




Comments
Comment by Bill Karwin [ 16/Feb/07 02:47 PM ]
As of revision 3503:

There were 4 failures:
1) testHeaderEncoding2(Zend_MailTest)
testmail@example.com?Cc:foobar@example.com,testmail2@example.com,testmail3@ex
ample.com
Failed asserting that
<string:testmail@example.com?Cc:foobar@example.com,testmail2@example.com,test
mail3@example.com>
  contains ""=?iso-8859-1?Q?=E4=FC=F6=DF=C4=D6=DC?="
<testmail2@example.com>".
C:\zf\tests\Zend\MailTest.php:191

2) testGlobalName(Zend_Mail_MboxFolderTest)
exception raised while selecting existing folder and getting global name
C:\zf\tests\Zend\Mail\MboxFolderTest.php:134

3) testIterator(Zend_Mail_MboxFolderTest)
Failed asserting that
Array
(
)
  is equal to
Array
(
     [/subfolder] => subfolder
     [/subfolder/test.mbox] => test.mbox
     [/test.mbox] => test.mbox
)
.
array key </subfolder>: only in expected <subfolder>
array key </subfolder/test.mbox>: only in expected <test.mbox>
array key </test.mbox>: only in expected <test.mbox>

C:\zf\tests\Zend\Mail\MboxFolderTest.php:166

4) testKeyLocalName(Zend_Mail_MboxFolderTest)
Failed asserting that
Array
(
)
  is equal to
Array
(
     [/subfolder] => subfolder
     [/subfolder/test.mbox] => test.mbox
     [/test.mbox] => test.mbox
)
.
array key </subfolder>: only in expected <subfolder>
array key </subfolder/test.mbox>: only in expected <test.mbox>
array key </test.mbox>: only in expected <test.mbox>

C:\zf\tests\Zend\Mail\MboxFolderTest.php:187
Comment by Nico Edtinger [ 16/Feb/07 06:03 PM ]
The tests in Zend_Mail_MboxFolderTest should be fixed by #3505. Sorry, the task is not mentioned in the log
message because I didn't check for tasks earlier.
Comment by Matthew Weier O'Phinney [ 20/Feb/07 08:14 AM ]
Bill – please verify whether or not tests are still failing in Windows. They run fine from *nix type boxen at this time.
Comment by Bill Karwin [ 21/Feb/07 12:07 PM ]
Yes, I confirm that the test failures 2, 3, and 4 above now pass, testing with revision 3546, Windows XP, PHP 5.2.0.

        testGlobalName()
        testIterator()
        testKeyLocalName()

The first failure above still fails. We discussed this and have decided to mark it "incomplete" pending a fix.

        testHeaderEncoding2()


Comment by Matthew Weier O'Phinney [ 29/Mar/07 12:24 PM ]
Assigning to Nico.
Comment by Sebastian Nohn [ 29/Mar/07 02:54 PM ]
With current SVN (4265), these tests don't fail anymore on Ubuntu 6.06, PHP 5.2.1
Comment by Bill Karwin [ 03/Apr/07 06:07 PM ]
Revision number 4221 was the build for ZF 0.9.1 beta release.

Therefore this fix is going into ZF 0.9.2.
[ZF-857] parse error in Zend_Mail_Client_Smtp_Auth_Crammd5 Created:
05/Feb/07 Updated: 05/Jul/07 Resolved: 05/Feb/07
Status:                   Resolved
Project:                  Zend Framework
Component/s:              Zend_Mail
Affects Version/s:        None
Fix Version/s:            0.8.0

Type:                     Bug                           Priority:          Major
Reporter:                 Marc Bennewitz (GIATA mbH)    Assignee:          Simon Mundy
Resolution:               Fixed                         Votes:             0
Remaining Estimate: Not Specified
Time Spent:               Not Specified
Original Estimate:        Not Specified


Description
Hi,

the class "Zend_Mail_Client_Smtp_Auth_Crammd5" has a parse error in file
"incubarot/library/Zend/Mail/Client/Smtp/Auth/Crammd5.php" on line 66
-> ";" is missing




Comments
Comment by Marc Bennewitz (GIATA mbH) [ 05/Feb/07 02:03 PM ]
Edit: sorry the error is removed after update
Comment by Bill Karwin [ 05/Feb/07 02:49 PM ]
Assigning to Simon, since he did the fix already.
Comment by Bill Karwin [ 05/Feb/07 02:51 PM ]
Fixed in revision 3193.

php -l Crammd5.php passes.
[ZF-837] SendMail.php transport fails under PHP 5.2.0 Created: 31/Jan/07                                       Updated:
05/Jul/07 Resolved: 09/Feb/07
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       None
Fix Version/s:           None

Type:                    Bug                                  Priority:                Minor
Reporter:                Art Hundiak                          Assignee:                Matthew Weier O'Phinney
Resolution:              Not an Issue                         Votes:                   0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
Running the simple example from the manual fails with an exception when run under PHP 5.2.0.
Using a straight mail() function seems to work.

Following error is generated when running from the command line:

$ php email_test.php
/usr/sbin/sendmail: unexpected response 501 to RCPT TO command




Comments
Comment by Simon Mundy [ 31/Jan/07 10:07 PM ]
So far I'm not having much luck replicate it. I installed a fresh copy of PHP 5.2.0 on a Mac laptop (OS 10.4.8) and
then checked out the HEAD of the core ZFW library and it mailed to me without a hitch.

Could you run a tail -f on your mail log in one terminal and watch it whilst you run the script again. I'd be interested to
see the transcript (with hostnames removed of course!) to see what's actually happening on your side.

BTW Are you using a Windows box? I only ask in that most of the sendmail instances I've used on Linux and Mac
don't report an SMTP error directly to the mail client. I could be wrong here - please let me know if there's any other
environmental factor that could be contributing to it.
Comment by Art Hundiak [ 01/Feb/07 08:43 AM ]
It's a Linux box. Not sure how to get the version of sendmail. -v does not work. And I'm not sure how to get to the
logs. It's a shared host. Using latest svn version as well as some older versions.

If I change:
$mail->addTo('ahundiak@xxx.com', 'Art Hundiak');
To:
$mail->addTo('ahundiak@xxx.com');
Then it seems to work.

I'll try to track down exactly what is going on with the headers later. Bit of a pain working on a shared host.
Comment by Simon Mundy [ 03/Feb/07 10:22 AM ]
Could you try something - in the Zend_Mail_Transport_Sendmail class there's the line:-

if (!mail(
                         $this->recipients,
                         $this->_mail->getSubject(),
                         $this->body,
                         $this->header))

Could you try replacing that with:-

if (!mail(
                         str_replace('"', '', $this->recipients),
                         $this->_mail->getSubject(),
                         $this->body,
                         $this->header))

Just a hunch, maybe I'm totally off, but it seems weird that it falls over whenever you remove the mailbox alias. Since
the Mail object escapes them with double quotes it may be causing problems for the sendmail agent.
Comment by Art Hundiak [ 09/Feb/07 09:17 AM ]
I did some more tests and found that the problem seems to be in the way the server is setup.
$to = 'User <user@xxx.com';
mail($to,...);
Generates /usr/sbin/sendmail: unexpected response 501 to RCPT TO command

And i'm assuming that if php 5.2.0 really did mess this up then there would have a loud outcry.

So I guess we can close this issue. And I'll try to get the host to fix things up.
Comment by Art Hundiak [ 09/Feb/07 11:38 AM ]
Just in case anyonw is wondering, the host was running a "hacked up" version of mini_sendmail which was mangling
the addresses. All better now.
[ZF-788] Call to undefined function Zend_Mail_Exception() Created: 23/Jan/07
Updated: 05/Jul/07 Resolved: 08/Feb/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.7.0
Fix Version/s:          0.8.0

Type:                   Patch                            Priority:              Trivial
Reporter:               Marc Holzwarth                   Assignee:              Nico Edtinger
Resolution:             Fixed                            Votes:                 0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:          Mail.diff

Description
Call to undefined function Zend_Mail_Exception() in class Zend_Mail_Imap (from incubator)




Comments
Comment by Bill Karwin [ 25/Jan/07 09:07 AM ]
Assign to Matthew.
[ZF-638] setBodyText and getBodyText not being reciprocal Created: 12/Dec/06
Updated: 05/Jul/07 Resolved: 03/Apr/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.2.0
Fix Version/s:          0.9.2

Type:                   Improvement                         Priority:               Major
Reporter:               Franco A.                           Assignee:               Matthew Weier O'Phinney
Resolution:             Fixed                               Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
setBodyText, given a string representing the mail body creates an instance of Zend_Mime_Part.
getBodyText returns this instance from which (if I'm not mistaken) only the encoded content can be recovered.
It would be good to have a method to recover easily the original text given to setBodyText.




Comments
Comment by Bill Karwin [ 19/Dec/06 12:37 PM ]
Assigning to Matthew. Scheduling for fix in 0.7.
Comment by Matthew Weier O'Phinney [ 03/Apr/07 11:55 AM ]
I've added a flag to each of getBodyText) and getBodyHtml(); pass true to either of these, and you will receive the
content of the MIME part containing the text or html.

One difference, however: the content will be MIME encoded. As we don't have methods in Zend_Mime for easy
decoding of a single MIME part, this will have to be a separate issue.
Comment by Matthew Weier O'Phinney [ 03/Apr/07 11:56 AM ]
Functionality addedin r4328
[ZF-608] Zend_Mail_Transport_Abstract does not reset headers between
messages Created: 30/Nov/06 Updated: 05/Jul/07 Resolved: 30/Nov/06
Status:                Resolved
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     0.2.0
Fix Version/s:         0.6.0

Type:                  Bug                                 Priority:            Critical
Reporter:              Simon Mundy                         Assignee:            Simon Mundy
Resolution:            Fixed                               Votes:               0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified


Description
This bug shows itself only when a default mail adapter is set with Zend_Mail::setDefaultTransport(). If many mail
messages are created and sent in a single execution, the Zend_Mail_Transport_Abstract class will append each the
heads of each message to the existing header property, meaning that subsequent mails will push header information
into the message body.

A resolution was easily found - simply reset the header property every time
Zend_Mail_Transport_Abstract::_prepareHeaders() was called.
[ZF-589] Problem with mail attachment Created: 22/Nov/06                             Updated: 05/Jul/07 Resolved:
03/Feb/07
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail, Zend_Mime
Affects Version/s:       0.2.0
Fix Version/s:           0.8.0

Type:                    Bug                                  Priority:               Major
Reporter:                Franco A.                            Assignee:               Matthew Weier O'Phinney
Resolution:              Cannot Reproduce                     Votes:                  0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

File Attachments:            mail_after.txt       mail_before.txt         test.pdf

Description
I tried to send an attachment with a simple text mail using Zend_Mail::addAttachment() method, using default options.
The mail is generated correctly but there's some problem with the attachment, as it is malformed when received.

Using standard base64 encoding it looks that there's a problem with line breaks in the attachment bytes. After some
trial and error I had success in sending the attachment by setting Zend_Mime::LINELENGTH to 72 (instead of 74),
but I didn't investigate why.
Please let me know if something is needed to better understand the problem




Comments
Comment by Bill Karwin [ 28/Nov/06 05:50 PM ]
Assigning to Matthew, scheduling for 0.7.0 release.
Comment by Simon Mundy [ 28/Nov/06 07:54 PM ]
Hi Franco - what transport were you using? Can you snip a portion of the encoded message to show a before / after
of the lines that were affected? It may also help to know a little more about the environment you're sending the mail
from (Platform, Mail software, etc)
Comment by Franco A. [ 29/Nov/06 04:59 PM ]
Hi,
Transport is default mail(), here's a test script I used:

<?php
require_once 'Zend/Mail.php';
$mail = new Zend_MAil();
$mail->setBodyText("Test body");
$mail->setSubject("Test subject");
$mail->setFrom("removed@rem.ove");
$mail->addTo("removed@aaa");
$att = file_get_contents("test.pdf");
$at = $mail->addAttachment($att);
$at->filename = "test.pdf";
$mail->send();
?>
I'll attach two mail messages, one with no changes to Zend framework 0.2.0, the other with
Zend_Mime::LINELENGTH = 72. I'll also attach the original test.pdf file.
Platform is ubuntu linux 6, postfix, php 5.1.6, apache 2.0
Comment by Simon Mundy [ 29/Nov/06 06:51 PM ]
Thanks for the info. I've tried a number of scenarios and can't reproduce the problem you're seeing.

There's a couple of things that may help identify the problem as well - could you try sending the message with
different line endings? You can use the code below to change the line ending to either "\r\n" or "\n" to see if that
changes anything.

$transport = new Zend_Mail_Transport_Sendmail();
$transport->EOL = "\n";

$mail = new Zend_Mail();
$mail->setBodyText("Test body");
$mail->setSubject("Test subject");
$mail->setFrom("test@test.com");
$mail->addTo("test@test.com");
$att = file_get_contents("test.pdf");
$at = $mail->addAttachment($att);
$at->filename = "test.pdf";
$mail->send($transport);

Secondly, I'm scratching my head wondering why 74 chars has been used when 76 chars is the RFC2045
recommendation. Can you revert back to 74 chars for the above test, then perform another round of tests with 76
chars and see if that changes anything? I'm interested to see if your local mail (Postfix) is being difficult. You may
also wish to try the SMTP transport to see if the problem persists.
Comment by Franco A. [ 30/Nov/06 05:02 PM ]
Hi,
I had no luck with "\n" but it works if I comment the second line ($transport->EOL = "\n"        and set LINELENGTH to
76. Looking at the mail files I attached I noticed that, for each line, the sequence \r\n is repeated twice (there's a blank
line between one encoded line and the other). MAybe this could be of some help.
Comment by Franco A. [ 19/Dec/06 08:32 AM ]
I experimented a bit with this issue, here's what I discovered:

1. I couldn't make Zend_Mail_Transport_Smtp work, even with a small email:

//I tried this server, maybe another one will work
$tr = new Zend_Mail_Transport_Smtp("smtp.tiscali.it");
Zend_Mail::setDefaultTransport($tr);
$m = new Zend_Mail();
$m->setFrom("valid@email.addr");
$m->addTo("valid@email.addr");
$m->setSubject("Blah blah blah");
$m->setBodyText("AAAAA");
$m->send();

With this code I get an error 554 Message refused

2. Using Zend_Mail_Transport_Smtp passing "localhost" (Ubuntu 6.10 with Postfix installed) to the constructor I can
send the mail correctly, even with LINELENGTH=74, so for now I'll be using this method.
Comment by Simon Mundy [ 03/Feb/07 10:06 AM ]
Closed for now - but If this resurfaces and we can get some more tangible tests then it will be given some further
consideration.
[ZF-580] Quoted printable remove dot from message Created: 21/Nov/06                                            Updated:
05/Jul/07 Resolved: 18/Mar/07
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       0.2.0
Fix Version/s:           0.9.1

Type:                    Bug                                   Priority:                 Major
Reporter:                Uros                                  Assignee:                 Simon Mundy
Resolution:              Fixed                                 Votes:                    0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
When sending mail in utf-8 and using quoted printable encoding there is problem with (.) dot character if this char is
placed at wrap position.
for example

&email=3Duser@domain.=
com

if text is

&email=3Duser1@domain.=
com

then . after domain is removed and you actually get

&email=3Duser1@domain=
com

This happened in html and text mode.




Comments
Comment by Bill Karwin [ 28/Nov/06 05:50 PM ]
Assigning to Matthew, scheduling for 0.7.0 release.
Comment by Uros [ 21/Dec/06 08:44 AM ]
I test this with latest trunk and it look like this was duplicate of . But I see that there was still problems with some line
endings. What's the status of this problem?
Comment by Simon Mundy [ 16/Mar/07 03:26 AM ]
Hi Uros - can you see this behaviour any more?
Comment by Uros [ 16/Mar/07 04:08 AM ]
No
Comment by Simon Mundy [ 18/Mar/07 06:08 AM ]
Resolved from previous fixes to Zend_Mime/Mail
Comment by Bill Karwin [ 19/Mar/07 11:39 AM ]
Changing fix version to 0.9.1.
[ZF-575] cumulative recipient when mail generate with a foreach
structure. Created: 21/Nov/06 Updated: 05/Jul/07 Resolved: 16/Feb/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      None
Fix Version/s:          0.8.0

Type:                   New Feature                         Priority:             Major
Reporter:               Jean-Claude GLOMBARD                Assignee:             Simon Mundy
Resolution:             Fixed                               Votes:                3
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description

First of all, excuse my poor english level

An exemple for explain the issue.
In the code bellow, i espect to have 4 emails. Each one whith 1 recipient.
In fact i receved 4 emails with cumulative recipient.

mail 1 : To: first@somewhere.net
mail 2 : To: first@somewhere.net, second@somewhere.net
mail 3 : To: first@somewhere.net, second@somewhere.net, first@anotherone.net
mail 4 : To: first@somewhere.net, second@somewhere.net, first@anotherone.net, second@anotherone.net
________________________________________

...
$this->emailList['first@somewhere.net']                         =    new   stdClass();
$this->emailList['second@somewhere.net']                        =    new   stdClass();
$this->emailList['first@anotherone.net']                        =    new   stdClass();
$this->emailList['second@anotherone.net']                       =    new   stdClass();

...

foreach ( $this->emailList as $toEmail => $el) {
  $mail = new Zend_Mail('UTF-8');

    $mail->setBodyHtml($this->generateHtmlBody($el));

    $mail->addTo($toEmail,$toEmail);
    $mail->setSubject('test mail');

    $mail->send();
    unset($mail);
}


Comments
Comment by Bill Karwin [ 28/Nov/06 05:50 PM ]
Assigning to Matthew, scheduling for 0.7.0 release.
Comment by Simon Mundy [ 03/Feb/07 09:40 AM ]
The code snippet supplied is, in fact, working as intended. For each loop iteration you are calling addTo, which is
exactly what the Zend_Mail object is doing and therefore you end up with cumulative recipients.

I suggest that this is really more of a feature request, as the behaviour you are expecting is more likely to be resolved
with a 'setTo()' method.

To this end, could I also suggest the following to assist with better control over the behaviour of Zend_Mail:-

         setTo() - clears current 'To' headers before adding recipient
         hasHeader($id) - returns boolean for existence of a header name (will be called from setTo())
         removeHeader() - removes header from mail object (will be called from setTo())

I believe the hasHeader and removeHeader deserve to be public methods to complement the addHeader method.

If there's no strong objection we can hopefully add these shortly.
Comment by Simon Mundy [ 03/Feb/07 09:48 AM ]
I just saw the 'unset($mail)' there so I guess you WERE expecting the mail to only have one address. This particular
issue may have been resolved by - can you please verify?
Comment by Jean-Claude GLOMBARD [ 16/Feb/07 03:07 AM ]
It's ok now...
Good job
[ZF-571] MAIL FROM and RCPT TO commands in Mail/Transport/SMTP
have extraneous space Created: 19/Nov/06 Updated: 05/Jul/07 Resolved: 28/Nov/06
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      None
Fix Version/s:          0.6.0

Type:                   Bug                               Priority:               Major
Reporter:               Brian Blood                       Assignee:               Simon Mundy
Resolution:             Fixed                             Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
RFC821 Section 3.1 and RFC2821 Section 3.3 define the format of the MAIL FROM and RCPT TO SMTP
commands:

MAIL <SP> FROM:<reverse-path> <CRLF>
RCPT <SP> TO:<forward-path> <CRLF>

The current Framework places a space character between the "colon" and the "less-than" characters:

$this->_send('MAIL FROM: <'.$from_email.'>');
$this->_send('RCPT TO: <' .$to. '>');

SMTP library developers need to do things better and cleaner than the next guy.
There are ISPs that are starting to block (quite a large amount) of spam based on these syntax checks.




Comments
Comment by Bill Karwin [ 19/Nov/06 12:56 PM ]
Assign to Matthew.
Comment by Bill Karwin [ 28/Nov/06 05:51 PM ]
Scheduling for 0.7.0 release.
[ZF-564] Add fluent interfaces to Zend_Mail Created: 18/Nov/06                                Updated: 05/Jul/07 Resolved:
03/Apr/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.2.0
Fix Version/s:          0.9.2

Type:                   Improvement                           Priority:               Minor
Reporter:               Nico Edtinger                         Assignee:               Matthew Weier O'Phinney
Resolution:             Fixed                                 Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified

File Attachments:           Zend_Mail.patch

Description
As reported by Waldemar Schott on fw-general:

I think it would be nice if Zend_Mail supports fluent interfaces like other parts of the framework.

$mail = new Zend_Mail();
$mail->setBodyText('This is the text of the mail.')
->setFrom('somebody@example.com', 'Some Sender')
->addTo('somebody_else@example.com', 'Some Recipient')
->setSubject('TestSubject')
->send();|




Comments
Comment by Nico Edtinger [ 18/Nov/06 01:39 PM ]
Patch adds fluent interface to all add* and set* methods except addAttachment().
Comment by Bill Karwin [ 19/Nov/06 12:56 PM ]
Assign to Matthew.
Comment by Bill Karwin [ 28/Nov/06 05:51 PM ]
Scheduling for 0.7.0 release.
Comment by Matthew Weier O'Phinney [ 03/Apr/07 04:55 PM ]
Finalized in r4327
[ZF-540] Expose _encodeHeader() as a public static method Created: 11/Nov/06
Updated: 05/Jul/07 Resolved: 18/Mar/07
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       0.2.0
Fix Version/s:           None

Type:                    Improvement                          Priority:                   Major
Reporter:                Shahar Evron                         Assignee:                   Matthew Weier O'Phinney
Resolution:              Not an Issue                         Votes:                      0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
Currently, it is very hard to add encoded headers using addHeader(). This can be easily solved if the
_encodeHeader() method would be exposed as a public static method.

This is very useful for adding headers like 'reply-to'.




Comments
Comment by Bill Karwin [ 13/Nov/06 03:01 PM ]
Assigning Zend_Mail issue to Matthew.
Comment by Bill Karwin [ 13/Nov/06 03:01 PM ]
Correct typo error in summary.
Comment by Bill Karwin [ 28/Nov/06 05:51 PM ]
Scheduling for 0.7.0 release.
Comment by Simon Mundy [ 03/Feb/07 10:08 AM ]
Hi Shahar - what's the difficult with addHeader()? Is it incorrectly encoding part of the header? Or did you want to add
pre-encoded headers for some reason?
Comment by Shahar Evron [ 18/Mar/07 06:34 AM ]
Sorry for not getting back on this for a long period - I reported this a while back ago when I tried encoding a reply-to
header and it seemed difficult to do. Looking at Zend_Mail now, it seems to be much easier - maybe the code has
changed since or maybe I missed something back then. Apparently nobody else but me had such issues

I suggest closing this bug for now - if I even encounter issues again I will reopen it.
Comment by Simon Mundy [ 18/Mar/07 06:42 AM ]

Closed as per Shahar's comments!
[ZF-459] not space between sendername to mailaddress Created: 24/Oct/06                                 Updated:
05/Jul/07 Resolved: 16/Mar/07
Status:                   Resolved
Project:                  Zend Framework
Component/s:              Zend_Mail
Affects Version/s:        0.1.5
Fix Version/s:            0.9.0

Type:                     Bug                                Priority:        Major
Reporter:                 Naoki Watanabe                     Assignee:        Simon Mundy
Resolution:               Fixed                              Votes:           0
Remaining Estimate: Not Specified
Time Spent:               Not Specified
Original Estimate:        Not Specified


Description
Hello all from japan.
I try to send multi-byte character mail from Zend_Mail, but result is bad.

Bad point of received mail is follow

=?iso-2022-jp?Q?"=1B$B=3F7=3DIE9=1B(B"=20?=<icebreaker@b-synapse.com>

There is not space between sendername to mailaddress

I think ...

Mail.php

protected function _addRecipientAndHeader($headerName, $name, $email)
    {
        $email = strtr($email,"\r\n\t",'???');
        $this->_addRecipient($email, ('To' == $headerName) ? true : false);
        if ($name != '') {
            $name = $this->_encodeHeader('"' .$name. '" ');   <---- matter?
        }

              $this->_storeHeader($headerName, $name .'<'. $email . '>', true);
       }

One space is given to encodeHeader then this space is replace to '=20' by Zend_Mime::encodeQuotedPrintable.

I think this action is bad.




Comments
Comment by Bill Karwin [ 28/Nov/06 05:51 PM ]
Scheduling for 0.7.0 release.
Comment by Simon Mundy [ 03/Feb/07 09:28 AM ]
Hi Naoki

Could you please attach a code snippet of your mail script so that I can replicate this? Just a single .php file will be
fine.

Cheers!
Comment by Naoki Watanabe [ 08/Feb/07 12:33 AM ]
Hi Simon.

I think that it is right by the following chage.

Mail.php

protected function _addRecipientAndHeader($headerName, $name, $email)
    {
        $email = strtr($email,"\r\n\t",'???');
        $this->_addRecipient($email, ('To' == $headerName) ? true : false);
        if ($name != '') {
            $name = $this->_encodeHeader('"' .$name. '"');   <---- erase
space
        }

        $this->_storeHeader($headerName, $name .' <'. $email . '>', true);
<---- add space before '<'
    }
Comment by Simon Mundy [ 08/Feb/07 12:53 AM ]
I've just committed a patch to subversion - could you please checkout the latest SVN version (r3290) and confirm that
this issue has been resolved?
[ZF-458] Adding Authentication to Zend_Mail_Transport_Smtp? Created:
24/Oct/06 Updated: 05/Jul/07 Resolved: 16/Feb/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.1.5
Fix Version/s:          0.8.0

Type:                   Improvement                        Priority:               Major
Reporter:               Wes Smith                          Assignee:               Simon Mundy
Resolution:             Fixed                              Votes:                  1
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
Granted I am sorta a php newbie... I need Authenication in the smtp transport. I played around with the smtp file and
came up with this that I use now.
Is there any problem doing this?

$tr = new Zend_Mail_Transport_Smtp('mail.host.com', 25, '127.0.0.1', 'username', 'passwd');

then in the Zend/Mail/Transport/Smtp.php



    /**
      * Constructor.
      *
      * @param string $host
      * @param int $port
      * @param string $myName (for use with HELO)
      * @param string $username
      * @param string $passwd
      */
    public function __construct($host = '127.0.0.1', $port=25,
$myName='127.0.0.1', $username=null, $passwd=null)
    {
         $this->_host = $host;
         $this->_port = $port;
         $this->_myName = $myName;
         ////
         $this->_username = $username;
         $this->_passwd = $passwd;
         ////
    }


      /**
       * Connect to the server with the parameters given
       * in the constructor and send "HELO". The connection
       * is immediately closed if an error occurs.
       *
      * @throws Zend_Mail_Transport_Exception
      */
    public function connect()
    {
         $errno = null;
         $errstr = null;

        // open connection
        $fp = stream_socket_client('tcp://'.$this->_host.':'.$this->_port,
$errno, $errstr, self::CONNECTION_TIMEOUT);

        if ($fp===false) {
            if ($errno==0) {
                $msg = 'Could not open socket';
            } else {
                $msg = $errstr;
            }
            throw new Zend_Mail_Transport_Exception($msg);
        }

        $this->_con = $fp;

        try {
            $res = stream_set_timeout($this->_con,
self::COMMUNICATION_TIMEOUT );
            if ($res === false) {
                throw new Zend_Mail_Transport_Exception('Could not set Stream
Timeout');
            }

            /**
             * Now the connection is open. Wait for the welcome message:
             *   welcome message has error code 220
             */
            $this->_expect(220);
            $this->helo($this->_myName);

            ///////
            if (isset($this->_username)) $this->authenticate($this-
>_username, $this->_passwd);
            ///////

        } catch (Zend_Mail_Transport_Exception $e) {
            fclose($fp);
            throw $e;
        }
    }




    /**
     * Sends AUTH to the server and validates the response. If valid,
username is sent to the
     * server and validates the response. If valid, password is sent to the
server and validates
        * the response.
        *
        * @param string $username
        * @param string $passwd
        * @throws Zend_Mail_Transport_Exception
        */
      public function authenticate($username, $passwd)
      {
           $this->_send('AUTH LOGIN');
           $this->_expect(334);


            $this->_send(base64_encode($username));
            $this->_expect(334);

            $this->_send(base64_encode($passwd));
            $this->_expect(235);

      }


Comments
Comment by Bill Karwin [ 28/Nov/06 05:51 PM ]
Scheduling for 0.7.0 release.
Comment by Justin Hendrickson [ 02/Feb/07 05:32 PM ]
I submitted this on the mailing list and they asked I put this over here. Here's my Smtp Auth library.

require_once 'Zend/Mail/Transport/Smtp.php';

class Zend_Mail_Transport_Smtp_Auth extends Zend_Mail_Transport_Smtp {

      /**#@+
       * Authentication types
       * @var string
       */
      const LOGIN = 'LOGIN';
      const PLAIN = 'PLAIN';
      /**#@-*/

    /**
     * @param string $username
     * @param string $password
     * @param string $method
     */
    protected function authenticate($username, $password, $method =
self::PLAIN) {
        switch($method) {
            case self::LOGIN:
                $this->authenticateLogin($username, $password);
            break;

                  case self::PLAIN:
                      $this->authenticatePlain($username, $password);
                  break;
            }
      }

      /**
       * @param string $username
       * @param string $password
       * @throws Zend_Mail_Transport_Exception
       */
      protected function authenticateLogin($username, $password) {
          $this->_send('AUTH LOGIN');

            try {
                $this->_expect(334);
            } catch(Zend_Mail_Transport_Exception $e) {
                if(substr($e->getMessage(), 0, 3) == 503) {
                    return;
                }
                throw $e;
            }

            $this->_send(base64_encode($username));
            $this->_expect(334);
            $this->_send(base64_encode($password));
            $this->_expect(235);
      }

      /**
       * @param string $username
       * @param string $password
       * @throws Zend_Mail_Transport_Exception
       */
      protected function authenticatePlain($username, $password) {
          $this->_send('AUTH PLAIN');

            try {
                $this->_expect(334);
            } catch(Zend_Mail_Transport_Exception $e) {
                if(substr($e->getMessage(), 0, 3) == 503) {
                    return;
                }
                throw $e;
            }

            $this->_send(base64_encode(chr(0) . $username . chr(0) . $password));
            $this->_expect(235);
      }

}

Use of the authentication methods is not directly tied into the connection process, but if it is so desired, you could also
add this:

class Zend_Mail_Transport_Smtp_Auth extends Zend_Mail_Transport_Smtp {
    private $_username;
    private $_password;
    private $_method;
    public function __construct($host = '127.0.0.1', $port=25,
$myName='127.0.0.1', $username=null, $password=null, $method=null) {
        parent::__construct($host, $port, $myName);
        $this->_username = $username;
        $this->_password = $password;
        $this->_method = $method;
    }
    public function connect() {
        parent::connect();
        if($username) {
            $this->authenticate($this->_username, $this->_password, $this-
>_method);
        }
    }
}
Comment by Justin Hendrickson [ 02/Feb/07 05:33 PM ]
if($username) {
            $this->authenticate($this->_username, $this->_password, $this-
>_method);
        }

This should be:
Comment by Gavin [ 02/Feb/07 08:18 PM ]

Thanks Justin
Comment by Simon Mundy [ 03/Feb/07 09:19 AM ]
Could you please try the latest checkout from trunk (r3168) and try the incubator version of
Zend_Mail_Transport_Auth?

An example usage of code would be:-

require_once 'Zend/Mail/Transport/Smtp.php';

$config = array('auth' => 'plain', // defaults to FALSE,
                'username' => 'myusername', // defaults to NULL,
                'password' => 'mypass', // defaults to NULL,
                'port' => 25, // defaults from php.ini,
                'host' => 'localhost'); // for EHLO

$tr = new Zend_Mail_Transport_Smtp('mail.someone.com', $config);

require_once 'Zend/Mail.php';

$mail = new Zend_Mail();
$mail->setBodyText('This is the text of the mail.');
$mail->setFrom('your.email@someone.com', 'Some Sender');
$mail->addTo('their.email@someone.com', 'Some Recipient');
$mail->setSubject('TestSubject');
$mail->send($tr);

The new transport supports 'auth' and 'plain' as auth methods and Cram-md5 is scheduled for 0.9
Comment by Gavin [ 07/Feb/07 07:05 PM ]
Post ZF 1.0, perhaps we can consider TLS/SASL support.
However, probably less than 5% of all ZF users would use this, so don't let the idea distract anyone from more
important work.
Comment by Simon Mundy [ 16/Feb/07 05:46 AM ]
Moved to core for 0.8
[ZF-455] Zend_Mail_Transport_Smtp::__construct() defaults to port 25,
instead of using default in php.ini Created: 20/Oct/06 Updated: 05/Jul/07 Resolved: 28/Nov/06
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      None
Fix Version/s:          0.6.0

Type:                   Bug                                  Priority:                Minor
Reporter:               Gavin                                Assignee:                Simon Mundy
Resolution:             Fixed                                Votes:                   0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
Zend_Mail_Transport_Smtp::__construct() defaults to port 25, instead of using a default in php.ini

The smtp_port setting in php.ini should be used, instead of "25", if available.

The complete set of cascaded defaults from lowest to highest priority:

Zend_Mail_Transport_Smtp => php.ini => ZF Global "INI" (Zend_Registry_Defaults) => Zend_Registry => parameter
to __construct()

Thus, the port used should be the port specified by the corresponding argument to
Zend_Mail_Transport_Smtp::__construct(). If none was specified, then the corresponding setting in Zend_Registry
should be used, but if that setting does not exist, then the value in php.ini should be used. If the value also does not
exist in php.ini, then a hard-wired value of 25 should be used.

Zend_Registry receives initializations from Zend_Registry_Defaults (proposal not yet published formally).




Comments
Comment by Bill Karwin [ 28/Nov/06 05:51 PM ]
Scheduling for 0.7.0 release.
[ZF-435] Error on svn up Created: 11/Oct/06              Updated: 19/Dec/08 Resolved: 13/Oct/06
Status:                 Closed
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.2.0
Fix Version/s:          None

Type:                   Bug                               Priority:              Major
Reporter:               Sergey Belov                      Assignee:              Nico Edtinger
Resolution:             Fixed                             Votes:                 0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
There is an error on svn up with TortoiseSVN:

Error: In directory 'W:\usr\svn_libs\zend\incubator\tests\Zend\Mail_files\test.maildir\cur'
Error: Can't move
'W:\usr\svn_libs\zend\incubator\tests\Zend\Mail_files\test.maildir\cur\.svn\tmp\1000000000.P1.example.org:2,S.tmp.t
mp' to
'W:\usr\svn_libs\zend\incubator\tests\Zend\Mail_files\test.maildir\cur\.svn\tmp\1000000000.P1.example.org:2,S.tmp':
Error: File path syntax error




Comments
Comment by Andries Seutens [ 13/Oct/06 04:39 AM ]
This issue has been resolved by Nico Edtinger
Comment by Wil Sinclair [ 19/Dec/08 01:02 PM ]
Bookkeeping. Closing old issues and assigning them to the person who ultimately resolved the issue.
[ZF-342] Enable Zend_Mail to send s/mime signed and/or encrypted mail.
Created: 28/Aug/06 Updated: 04/Dec/08 Resolved: 04/Dec/08
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.1.5
Fix Version/s:          None

Type:                   New Feature                          Priority:                Minor
Reporter:               Kevin McArthur                       Assignee:                Nico Edtinger
Resolution:             Won't Fix                            Votes:                   4
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
It would be useful for the Zend_Mail component to be able to send signed/encrypted email using the S/MIME
standard. This could further guarantee that the email originated from the server, encryption could increase security in
various applications that may pass customer information like email addresses and phone numbers in server
generated email.




Comments
Comment by Bill Karwin [ 13/Nov/06 03:19 PM ]
Changing fix version to unknown.
Comment by Bill Karwin [ 28/Nov/06 05:51 PM ]
Scheduling for 0.7.0 release.
Comment by Matthew Weier O'Phinney [ 29/Jan/08 12:50 PM ]
Unassigning so someone else can pick it up.
Comment by Wil Sinclair [ 18/Apr/08 03:48 PM ]
Please evaluate and categorize/assign as necessary.
Comment by Kevin McArthur [ 04/Dec/08 01:53 PM ]
Closing old issue - as per Wil's "or that we will never fix" cleanup request. Re-open it if anyone plans to work on this.
[ZF-328] Zend_Mail / Zend_Mime does not allow use of 'Content-type:
multipart/related' Created: 19/Aug/06 Updated: 31/Oct/09 Resolved: 03/Apr/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail, Zend_Mime
Affects Version/s:      None
Fix Version/s:          0.9.2

Type:                   Bug                              Priority:               Major
Reporter:               Adam Wagner                      Assignee:               Matthew Weier O'Phinney
Resolution:             Fixed                            Votes:                  2
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
For messages with attachments, the Content-type header is always set to multipart/mixed.

A constant Zend_Mime::MULTIPART_RELATED exists, but never seems to be used, and manually changed content-
type headers get overwritten in Zend_Mail_Transport_Abstract::_getHeaders()

See for more info:
library/Zend/Mime.php:45
library/Zend/Mail/Abstract.php:133,137




Comments
Comment by Bill Karwin [ 28/Nov/06 05:51 PM ]
Scheduling for 0.7.0 release.
Comment by Roman Roan [ 12/Dec/06 05:49 AM ]
Patch:

Index: /Zend/Mail/Transport/Abstract.php
===================================================================
--- /Zend/Mail/Transport/Abstract.php (revision 273)
+++ /Zend/Mail/Transport/Abstract.php (revision 274)
@@ -130,10 +130,13 @@
         if (null !== $boundary) {
             // Build multipart mail
-            if ($this->_mail->hasAttachments) {
-                 $type = Zend_Mime::MULTIPART_MIXED;
-            } elseif ($this->_mail->getBodyText() && $this->_mail-
>getBodyHtml()) {
-                 $type = Zend_Mime::MULTIPART_ALTERNATIVE;
-            } else {
-                 $type = Zend_Mime::MULTIPART_MIXED;
+            $type = $this->_mail->getType();
+            if (!$type) {
+                    if ($this->_mail->hasAttachments) {
+                                $type = Zend_Mime::MULTIPART_MIXED;
+                            } elseif ($this->_mail->getBodyText() && $this->_mail-
>getBodyHtml()) {
+                                $type = Zend_Mime::MULTIPART_ALTERNATIVE;
+                            } else {
+                                $type = Zend_Mime::MULTIPART_MIXED;
+                            }
             }

Index: /Zend/Mail.php
===================================================================
--- /Zend/Mail.php (revision 273)
+++ /Zend/Mail.php (revision 274)
@@ -77,4 +77,10 @@
     protected $_charset = null;

+          /**
+       * Mail content type
+       * @var string
+       */
+      protected $_type = null;
+
     /**
       * Mail headers
@@ -172,4 +178,25 @@
     {
          return $this->_charset;
+    }
+
+    /**
+      * Sets Content-type of the message
+      *
+      * @param string $email
+      */
+    public function setType($type)
+    {
+         $this->_type = $type;
+    }
+
+    /**
+      * Return content type
+      *
+      * @access public
+      * @return string
+      */
+    public function getType()
+    {
+         return $this->_type;
     }
Comment by Matthew Weier O'Phinney [ 03/Apr/07 12:40 PM ]
Resolved in r4329. setType() only allows setting multipart content-types, and only accessed when a boundary is
detected in the transport.
[ZF-326] SMTP transport is not prepending dots to lines beginning with a
dot Created: 18/Aug/06 Updated: 18/Jan/08 Resolved: 18/Jan/08
Status:                  Resolved
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       0.1.5
Fix Version/s:           None

Type:                    Bug                                  Priority:                Major
Reporter:                Matthew Leverton                     Assignee:                Simon Mundy
Resolution:              Fixed                                Votes:                   3
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified

File Attachments:            smtp-dot.diff      UPDATED-smtp-dot.diff
Issue Links:             Duplicate
                         is duplicated by         ZF-2074        Zend_mail lose dot in mail                 Resolved

Description
Zend/Mail/Transport/Smtp.php does not insert a leading dot for every line that begins with a dot. I've quoted the RFC
below.

See Section 4.5.2 of RFC 2821

          Before sending a line of mail text, the SMTP client checks the
           first character of the line. If it is a period, one additional
           period is inserted at the beginning of the line.

          When a line of mail text is received by the SMTP server, it checks
           the line. If the line is composed of a single period, it is
           treated as the end of mail indicator. If the first character is a
           period and there are other characters on the line, the first
           character is deleted.




Comments
Comment by Matthew Leverton [ 18/Aug/06 11:00 AM ]
A patch to conform to the RFC.
Comment by Simon Mundy [ 20/Sep/06 06:28 PM ]
I've updated the priority to Major, as this still has the potential to mangle emails (e.g. broken images) in rare
situations.

Further to this, I discovered that Matthew Leverton's patch still wasn't catching a few examples of lines where the
leading character was a '.'. I traced it back to the fact that Zend_Mail_Transport_Abstract defines a line end as '/r/n'
whereas Zend_Mime was using '/n' as a line end.

Substituting $this->EOL with Zend_Mime::LINEEND did the trick - here's the diff (and will attach separately):-
===================================================================
— library/Zend/Mail/Transport/Smtp.php (revision 1084)
+++ library/Zend/Mail/Transport/Smtp.php (working copy)
@@ -187,10 +187,10 @@
{
$this->_send('DATA');
$this->_expect(354);

        foreach(explode($this->EOL, $data) as $line) {
        if ($line=='.') {
         + foreach(explode(Zend_Mime::LINEEND, $data) as $line)

         Unknown macro: {+ if (strpos($line, '.') === 0) { // important. replace single dot on a line - $line='..'; + $line =
         '.' . $line; } $this->_send($line); }
Comment by Simon Mundy [ 20/Sep/06 06:28 PM ]
Fixes erroneous detection of line endings
Comment by Bill Karwin [ 28/Nov/06 05:51 PM ]
Scheduling for 0.7.0 release.
Comment by Aren Sandersen [ 11/Jul/07 04:40 PM ]
This issue has regressed. Simon's comments on 20 Sep still apply – the "foreach(explode($this->EOL, $data) as
$line) { " (now in Mail/Protocol/Smtp.php) is using self::EOL instead of Zend_Mime::LINEEND.
Comment by Darby Felton [ 12/Jul/07 06:48 AM ]
Reopening on behalf of      Aren Sandersen.
Comment by Simon Mundy [ 14/Jul/07 04:06 PM ]
I'm not quite sure why this was re-opened - the updated patch applies to Zend_Mail_Transport_Smtp, but for a long
time now the handling of pre-prending the dot is carried out by Zend_Mail_Protocol_Smtp, and the code in data()
definitely handles the 'dot' correctly.
Comment by Aren Sandersen [ 15/Jul/07 08:14 PM ]
Zend_Mime's encodeQuotedPrintable() uses LINEND ("\n") as the line-break sequence, but
Zend_Mail_Protocol_Smtp's data() method is looking for self::EOL ("\r\n") as line-breaks. Since these don't match,
newlines inserted as a result of quoted-printable encoding aren't detected properly and this issue happens.

Please re-open.
Comment by Simon Mundy [ 17/Jul/07 05:50 AM ]
Further investigation of the issue by Aren Sandersen pointed to a logic error in Smtp components
Comment by Simon Mundy [ 17/Jul/07 05:52 AM ]
Resolution committed in SVN revision 5724 - please test and confirm the issue is fixed.
Comment by Aren Sandersen [ 17/Jul/07 03:26 PM ]
Confirmed; my tests show the issue is fixed.
Comment by Todd Rhodes [ 19/Jul/07 03:09 PM ]
This also fixed my missing dot issue, but seemed to introduce a new issue. When I use setBodyHtml() and
setBodyText() together to create the email, the resulting sent email only shows the text version with:

'Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable'

displayed at the top of the received email text. The text version of the email is shown, not the html as would be
expected. In addition, long email text is mangled and interspersed with various line break characters.
Comment by Darby Felton [ 30/Jul/07 09:29 AM ]
Fix version after 1.0.1.
Comment by Simon Mundy [ 05/Nov/07 07:50 PM ]
Todd, can you please verify this behaviour occurs in release 1.0.2? If so, can you please attach new files to this issue
with your code, the original message you are trying to send and - if possible - a dump of the resulting Zend_Mail
object just before it is sent.
Comment by Simon Mundy [ 18/Jan/08 09:31 PM ]
No further evidence of bug exists
[ZF-291] Mail without body triggering a fatal error instead of an
Exception Created: 28/Jul/06 Updated: 05/Jul/07 Resolved: 28/Jul/06
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      None
Fix Version/s:          0.2.0

Type:                   Bug                                  Priority:          Minor
Reporter:               Cristian Rodriguez R.                Assignee:          Matthew Weier O'Phinney
Resolution:             Fixed                                Votes:             0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
The following code should trigger an exception, but triggers a fatal error:
Tested latest SVN.

require_once 'Zend/Mail.php';

try {

$mail = new Zend_Mail();
//$mail->setBodyText();
$mail->setFrom('foo@example.com', 'Some Sender');
$mail->addTo('bar@example.com', 'Some Recipient');
$mail->setSubject('foobar');
$mail->send();

} catch(Zend_Mail_Exception $oops) {

            die("error :" . $oops->getMessage());
}

Expected Result :

error :No body specified

Actual result :

Fatal error: Call to a member function getHeadersArray() on a non-object in..

because $body IS set, but to FALSE.

Patch :

Index: Zend/Mail/Transport/Abstract.php
===================================================================
--- Zend/Mail/Transport/Abstract.php    (revisión: 924)
+++ Zend/Mail/Transport/Abstract.php    (copia de trabajo)
@@ -264,7 +264,7 @@
             array_unshift($this->_parts, $body);
         }

-            if (!isset($body)) {
+            if (is_bool($body)) {
                 throw new Zend_Mail_Transport_Exception('No body specified');
             }


Comments
Comment by Matthew Weier O'Phinney [ 28/Jul/06 03:40 PM ]
Fixed in commit 928
Comment by Cristian Rodriguez R. [ 28/Jul/06 03:46 PM ]
Thanks Matthew.
[ZF-259] Zend_Mail_Transport_Smtp::_receive timeout Created: 16/Jul/06                                      Updated:
05/Jul/07 Resolved: 05/Mar/07
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.1.4, 0.1.5
Fix Version/s:          0.8.0

Type:                   Improvement                         Priority:               Major
Reporter:               ambauen                             Assignee:               Simon Mundy
Resolution:             Fixed                               Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
when testing my implementation of Zend_Mail with an smtp transport, i found that the
Zend_Mail_Transport_Smtp::_receive method was irregularly throwing an 'Could not read from SMTP server'
exception immediately after calling send(). send expects a 250 response, expect calls receive and reads null from the
socket, throws an exception caught by _sendMail() which immediately calls disconnect().

disconnect sends 'QUIT' and expects a 221 response, but instead gets a 250 from the previous SEND. so the
problem is that my smtp server takes a few extra ms to respond (only happens after the message is complete). qmail
runs the message through spamassassin, clamav, qmail-scanner, procmail, etc.

my proposed solution is to run a loop, with usleep() to give the mail server some extra time to respond. the the
response never comes, then throw the exception. after testing, i've never had to sleep more than 100us.

my code below:

protected function _receive() {
$i = 0;
do {
$res = fgets($this->_con, 1024);
if ($res === false) {
if (self::DEBUG) { echo "received NONE, sleep 100us<br>\n"; }
usleep(100);
} else { break; }
} while ($i++ < 10);
if ($res === false) { throw new Zend_Mail_Transport_Exception('Could not read from SMTP server'); }
if (self::DEBUG) { echo "R: $res<br>\n"; }
return $res;
}




Comments
Comment by Bill Karwin [ 28/Nov/06 05:51 PM ]
Scheduling for 0.7.0 release.
Comment by Simon Mundy [ 03/Feb/07 09:15 AM ]
Could you please try the latest commit of the subversion (r3168) to see if this resolves the problem? The default
timeout was for 2 seconds which was probably too low for your environment
Comment by Simon Mundy [ 05/Mar/07 05:48 PM ]
Have fixed according to specs - if this bug reappears then will re-open this issue but otherwise should be completely
resolved.
[ZF-226] Sendmail does not send Bcc Created: 11/Jul/06                         Updated: 05/Jul/07 Due: 11/Jul/06
Resolved: 11/Jul/06
Status:                Closed
Project:               Zend Framework
Component/s:           Zend_Mail
Affects Version/s:     0.1.4
Fix Version/s:         0.1.5

Type:                  Bug                                  Priority:              Major
Reporter:              Matthew Weier O'Phinney              Assignee:              Matthew Weier O'Phinney
Resolution:            Fixed                                Votes:                 0
Remaining Estimate: Not Specified
Time Spent:            Not Specified
Original Estimate:     Not Specified


Description
Bcc's are not sent by the Sendmail transport (they are handled correctly by the Smtp transport).




Comments
Comment by Matthew Weier O'Phinney [ 11/Jul/06 10:39 AM ]
Fixed in 0.1.5 branch [886] and trunk [889]
Comment by Jayson Minard [ 11/Jul/06 11:54 AM ]
0.1.5 released
[ZF-195] Ability to set the MAIL FROM: to specify the Return-path when
using SMTP Created: 06/Jul/06 Updated: 05/Jul/07 Resolved: 28/Jul/06
Status:                 Resolved
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.1.4
Fix Version/s:          0.2.0

Type:                   Improvement                          Priority:               Major
Reporter:               Matthew Delmarter                    Assignee:               Matthew Weier O'Phinney
Resolution:             Fixed                                Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
The ability to specify the Return-path is quite useful, especially when wanting to direct bounces to a different address
from the Sender address. From my research and testing the MAIL FROM command in SMTP allows the Return-path
to be specifed.

It would be great if there was a way to specify the email address used by the following method in
Mail/Transport/Smtp.php.

public function mail_from($from_email)

{ $this->_send('MAIL FROM: <'.$from_email.'>'); $this->_expect(250); }

I hardcoded the $from_email and got the behaviour I was looking for. We really need to have a method that allows
this to be set on the fly as individual emails are being sent - maybe something like $mail->setReturnPath()...




Comments
Comment by Matthew Weier O'Phinney [ 07/Jul/06 09:48 PM ]
Not a blocker, as the mail component can be used without this feature. However, it would be nice to have, and has
been slated for the 0.2.0 release.
Comment by Gavin [ 25/Jul/06 11:16 AM ]
It should be noted in the final documentation that using an email address in SMTP's MAIL FROM that differs from the
mail header "From:" will increase the likelihood that anti-spam systems will file that email into the "junk/spam" folder.

Note that the mail header's "From:" can use any name in combination with an email address identical to whatever is
desired for MAIL FROM. For example,

From:       "My Name" <bounce_return_path@somedomain.com>

Thus, setting a different email address in MAIL FROM than in the "From:" mail header is not considered "best
practice", and generally should be discouraged. The "Reply-To:" header solves the issue of someone replying to the
bounce address, when the bounce address is using for the "From:" and "MAIL FROM".
Comment by Matthew Weier O'Phinney [ 28/Jul/06 12:57 PM ]
Reply-To is a non-standard mail header; Return-Path is standard and addressed in RFC-2821 as the appropriate
place to set an alternate address for bouncebacks.

I've updated Zend_Mail and Zend_Mail_Transport_Smtp to in commit 927 in SVN to address this; tests were also
written and pass.
[ZF-131] Zend_Mail_Transport_Abstract array_walk() creates E_NOTICE
Created: 22/Jun/06 Updated: 05/Jul/07 Due: 26/Jun/06 Resolved: 22/Jun/06
Status:                 Closed
Project:                Zend Framework
Component/s:            Zend_Mail
Affects Version/s:      0.1.3, 0.1.4
Fix Version/s:          0.1.4

Type:                   Bug                                  Priority:               Minor
Reporter:               Matthew Weier O'Phinney              Assignee:               Matthew Weier O'Phinney
Resolution:             Fixed                                Votes:                  0
Remaining Estimate: Not Specified
Time Spent:             Not Specified
Original Estimate:      Not Specified


Description
User Asger Hallas reports:

"I keep getting a warning about an undefined constant self in line 191 of the mail transport abstract:

array_walk($content, array(self, '_formatHeader'), $header);"




Comments
Comment by Matthew Weier O'Phinney [ 22/Jun/06 07:40 AM ]
This was an E_NOTICE produced by using the self keyword in a callback context. It has been fixed in patch 690.
[ZF-30] add a clearRecipients() method to the Zend_Mail (TRAC#14) Created:
19/Jun/06 Updated: 05/Jul/07 Resolved: 07/Jul/06
Status:                   Resolved
Project:                  Zend Framework
Component/s:              Zend_Mail
Affects Version/s:        0.1.3
Fix Version/s:            None

Type:                     Improvement                      Priority:               Minor
Reporter:                 Zend Framework                   Assignee:               Matthew Weier O'Phinney
Resolution:               Won't Fix                        Votes:                  0
Remaining Estimate: Not Specified
Time Spent:               Not Specified
Original Estimate:        Not Specified


Description
The second suggestion is to add a clearRecipients() method to the Zend_Mail class to optimize the process when
sending the same email to several receipients.

My criteria are : no use of the BCC, and I do not want users to see which other users has received the email.

Here is how I do it right now :

require_once('Zend/Mail.php');
require_once 'Zend/Mail/Transport/Smtp.php';

$tr = new Zend_Mail_Transport_Smtp('myMailServer');
$tr->connect();

foreach ($emails as $value) {
    $mail = new Zend_Mail();
    $mail->setFrom($from);
    $mail->setBodyText($message);
    $mail->setSubject('this is a test');
    $mail->addTo($value);
    $mail->send();
}

$tr->disconnect();

Here is my suggestion :

require_once('Zend/Mail.php');
require_once 'Zend/Mail/Transport/Smtp.php';

$tr = new Zend_Mail_Transport_Smtp('myMailServer');
$tr->connect();
$mail = new Zend_Mail();
$mail->setFrom($from);
$mail->setBodyText($message);
$mail->setSubject('this is a test');
foreach ($emails as $value) {
    $mail->clearRecipients();
    $mail->addTo($value);
    $mail->send();
}

$tr->disconnect();


Comments
Comment by Zend Framework [ 19/Jun/06 10:55 PM ]
Another feature creep likely to be requested: mail merge

Mail merge usually involves similar activities found in template instantiation, except for email the instantiation may be
once per email in a list, instead of once per page view for templates used to produce web pages. Consider a
common, but simple case, where the beginning of an email includes a greeting with the recipient's name, but the
remainder of the email remains identical.
Comment by Matthew Weier O'Phinney [ 07/Jul/06 09:46 PM ]
We have discussed this request internally, and decided not to add the feature at this time in anticipation of a proper
mail merge/queue module in a future release.

In the meantime, a very easy workaround exists for doing this. First, create the mail object with all information except
the recipients list:

$mail = new Zend_Mail();
$mail->setFrom('matthew@zend.com, "Matthew Weier O'Phinney");
$mail->setBodyText('This is the message body');

Then, loop over your recipients, clone the mail object, add recipients to the clone, and send:

foreach ($recpients as $to) {
$copy = clone $mail;
$copy->addTo($to);
$copy->send();
unset($copy);
}
[ZF-29] Add Platform to setFrom() method of Zend_Mail class (TRAC#13)
Created: 19/Jun/06 Updated: 19/Dec/08 Resolved: 26/Jun/06
Status:                  Closed
Project:                 Zend Framework
Component/s:             Zend_Mail
Affects Version/s:       0.1.3
Fix Version/s:           0.1.4

Type:                    Improvement                         Priority:              Minor
Reporter:                Zend Framework                      Assignee:              Matthew Weier O'Phinney
Resolution:              Cannot Reproduce                    Votes:                 0
Remaining Estimate: Not Specified
Time Spent:              Not Specified
Original Estimate:       Not Specified


Description
In the setFrom method of the Zend_Mail class, I would like to have another parameter accepting the platform of the
mail server :

ex.:

$mail->setFrom("test@test.com", "test", "unix");

or

$mail->setFrom("test@test.com", "test", "windows");

because my version of Microsoft Exchange does not accept the format of "From test <test@test.com>" it only accept
the "From test@test.com".

                   owner changed from zend to matthew.
                   status changed from new to assigned.

           Instead of an additional parameter, a new 'Exchange' transport may be the better option. Are there
           any other differences in how Exchange handles headers (To, Cc, Bcc, Subject, etc.) of which you
           are aware?




Comments
Comment by Matthew Weier O'Phinney [ 26/Jun/06 08:09 AM ]
We are unable to confirm this issue at this time.
Comment by Wil Sinclair [ 19/Dec/08 01:57 PM ]
Bookkeeping. Closing old issues and assigning them to the person who ultimately resolved the issue.
Generated at Sun Mar 27 05:32:16 GMT+00:00 2011 using JIRA 4.0#466.

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:1617
posted:4/6/2011
language:English
pages:427