zetacomponents / mail Goto Github PK

I need to be able to pass additional parameters to stream_socket_client so I can bind the connection to a particular network interface

see http://php.net/manual/en/context.socket.php

Hi,

Civicrm is using the ezcomponent mail library and we have had a pb recently with it (couldn't find the body of emails)

Is this library still maintained and active or should we consider moving to something else?

I'm working with imap, but the same is true of pop3 and smtp... when a user tries to authenticate, user names may contain spaces. That means that for imap, using LOGIN user pass will fail. The solution is to quote the username and password.

For imap in imap_transport.php, the line should become
$this->connection->sendData( "{$tag} LOGIN "{$user}" "{$password}"" );

It might be a good idea to only include quotes when $user or $password has spaces.

Tested on gmail and it works as above.

is it possible to parse mail to leave "as it is" the ".msg" attachment!?
instead of "inspecting it inside" ???

We have a new issue with mail components - the returnPath is capabil of being an invalid email in line with the Sender Rewriting scheme

e.g

Return-Path:  <SRS0=z9mA=EY=donate-long-name.example.org=b.51907682.51575594.57daed525aaca713@example.org>

However, this doesn't pass !filter_var( $value->email, FILTER_VALIDATE_EMAIL ) )

I'm playing catch up here a bit because I don't know why this wasn't raised in the context of #87 (our ref is https://lab.civicrm.org/dev/core/-/issues/3586)

However, the problem is that an SRS path - causes the whole email to fail to load - which is the problem

We have a proposed fix which is just to set NULL rather than throw an exception above in these cases - perhaps we can detect SRS in the string and just not return anything in that case?

I'm trying to fetch flags from messages in my GMail account while using UID Referencing. The flags are not being returned.

The reason for this is that GMail is not sending back the response to FETCH FLAGS in the order that the order that ezcMailImapTransport::fetchFlags() is expecting. This is the response I am seeing from GMail:

* 1 FETCH (UID 22 FLAGS (\Flagged \Seen))

in method finish() charset conversion should not be activated when text is already utf-8.

my version:

    /**
     * Returns the ezcMailText part corresponding to the parsed message.
     *
     * @return ezcMailText
     */
    public function finish()
    {
        $charset = "us-ascii"; // RFC 2822 default
        if ( isset( $this->headers['Content-Type'] ) )
        {
            preg_match( '/\s*charset\s?=\s?"?([^;"\s]*);?/i',
                            $this->headers['Content-Type'],
                            $parameters );
            if ( count( $parameters ) > 0 )
            {
                $charset = strtolower( trim( $parameters[1], '"' ) );
            }
        }

        $encoding = strtolower( $this->headers['Content-Transfer-Encoding'] );
        if ( $encoding == ezcMail::QUOTED_PRINTABLE )
        {
            $this->text = quoted_printable_decode( $this->text );
        }
        else if ( $encoding == ezcMail::BASE64 )
        {
            $this->text = base64_decode( $this->text );
        }
        if ($charset != 'utf-8') {
            $this->text = ezcMailCharsetConverter::convertToUTF8($this->text, $charset);
        }

        $part = new ezcMailText( $this->text, 'utf-8', ezcMail::EIGHT_BIT, $charset );
        $part->subType = $this->subType;
        $part->setHeaders( $this->headers->getCaseSensitiveArray() );
        ezcMailPartParser::parsePartHeaders( $this->headers, $part );
        $part->size = strlen( $this->text );
        return $part;
    }

I'm testing the waters for a potential PHP 7.4 upgrade in the future, my unit test suite is failing due to a deprecation warning.

Specifically, line 108 of src/tools.php uses $name{0} etc. I haven't looked around for any other usages like this.

The deprecation message is "PHP Deprecated: Array and string offset access syntax with curly braces is deprecated in …/vendor/zetacomponents/mail/src/tools.php on line 108"

zetacomponents/mail is at 1.8.4 which is the latest available release AFAIK.

I have the following repeated error when parsing email:

    [exception] => [object] (RuntimeException: fopen(/tmp/29810-1/=_utf-8_Q_=D0=9A=D0=BE=D1=80=D1=80=D0=B5=D0=BA=D1=82=D0=B8_= =_utf-8_Q_=D1=80=D0=BE=D0=B2=D0=BA=D0=B0_=D0=B7=D0=B0_= =_utf-8_Q_=D0=BA=D0=B0=D0=B7=D0=B0_=D0=BF=D0=BE=D0=BA_= =_utf-8_Q_=D1=83=D0=BF=D0=B0=D1=82=D0=B5=D0=BB=D1=8F__= =_utf-8_Q_=E2=84=96_=D0=A6=D0=9100000491_=D0=BE=D1=82_23=2E01=2E2012=2Ex_= =_utf-8_Q_ls_=): failed to open stream: File name too long on vendor/zetacomponents/mail/src/parser/parts/file_parser.php:170 at src/Amayama/Bootstrap.php:163:
#  13 : [internal function] Amayama\Bootstrap->errorHandler(2, 'fopen(/tmp/29810-1/=_utf-8_Q_=D0=9A=D0=BE=D1=80=D1=80=D0=B5=D0=BA=D1=82=D0=B8_= =_utf-8_Q_=D1=80=D0=BE=D0=B2=D0=BA=D0=B0_=D0=B7=D0=B0_= =_utf-8_Q_=D0=BA=D0=B0=D0=B7=D0=B0_=D0=BF=D0=BE=D0=BA_= =_utf-8_Q_=D1=83=D0=BF=D0=B0=D1=82=D0=B5=D0=BB=D1=8F__= =_utf-8_Q_=E2=84=96_=D0=A6=D0=9100000491_=D0=BE=D1=82_23=2E01=2E2012=2Ex_= =_utf-8_Q_ls_=): failed to open stream: File name too long', 'vendor/zetacomponents/mail/src/parser/parts/file_parser.php', 170, array[size:2])
#  12 : file_parser.php:170 fopen('/tmp/29810-1/=_utf-8_Q_=D0=9A=D0=BE=D1=80=D1=80=D0=B5=D0=BA=D1=82=D0=B8_= =_utf-8_Q_=D1=80=D0=BE=D0=B2=D0=BA=D0=B0_=D0=B7=D0=B0_= =_utf-8_Q_=D0=BA=D0=B0=D0=B7=D0=B0_=D0=BF=D0=BE=D0=BA_= =_utf-8_Q_=D1=83=D0=BF=D0=B0=D1=82=D0=B5=D0=BB=D1=8F__= =_utf-8_Q_=E2=84=96_=D0=A6=D0=9100000491_=D0=BE=D1=82_23=2E01=2E2012=2Ex_= =_utf-8_Q_ls_=', 'w')
#  11 : file_parser.php:142 ezcMailFileParser->openFile('=_utf-8_Q_=D0=9A=D0=BE=D1=80=D1=80=D0=B5=D0=BA=D1=82=D0=B8_= =_utf-8_Q_=D1=80=D0=BE=D0=B2=D0=BA=D0=B0_=D0=B7=D0=B0_= =_utf-8_Q_=D0=BA=D0=B0=D0=B7=D0=B0_=D0=BF=D0=BE=D0=BA_= =_utf-8_Q_=D1=83=D0=BF=D0=B0=D1=82=D0=B5=D0=BB=D1=8F__= =_utf-8_Q_=E2=84=96_=D0=A6=D0=9100000491_=D0=BE=D1=82_23=2E01=2E2012=2Ex_= =_utf-8_Q_ls_=')
#  10 : part_parser.php:150 ezcMailFileParser->__construct('application', 'octet-stream', [object] (ezcMailHeadersHolder))
#   9 : multipart_parser.php:184 ezcMailPartParser::createPartParserForHeaders([object] (ezcMailHeadersHolder))
#   8 : rfc822_parser.php:118 ezcMailMultipartParser->parseBody('
')
#   7 : rfc822_digest_parser.php:81 ezcMailRfc822Parser->parseBody('
')
#   6 : multipart_parser.php:196 ezcMailRfc822DigestParser->parseBody('
')
#   5 : rfc822_parser.php:118 ezcMailMultipartParser->parseBody('
')
#   4 : parser.php:252 ezcMailRfc822Parser->parseBody('
')
#   3 : ImportEmail.php:167 ezcMailParser->parseMail([object] (ezcMailVariableSet))

Please fix attachment file handling.

Please add the ability to parse the text file attachment as file when the Content-Disposition: attachment header exists for the part. I have a mail with following part configuartion:

Content-Type: text/html; name="=?UTF-8?B?Y2hlY2tfcHJpbnQuZG8uaHRtbA==?="
Content-Disposition: attachment
Content-Transfer-Encoding: base64

The createPartParserForHeaders method tries to parse this attachment as text part of the mail, so it tries to convert its encoding to utf-8 and fails, because it tries to interpret the part as 'us-ascii'. This is the attachment so it has no the encoding headers (actual file encoding can be any multibyte enoding to cause the mail parsing failure). If I set the ezcMailPartParser::$parseTextAttachmentsAsFiles to True the entire mail is parsed successfully, but it consists from attachments only, without any body text.

Suggested fix at part_parser.php:170:

if (ezcMailPartParser::$parseTextAttachmentsAsFiles === true || isset($headers['Content-Disposition']) && $headers['Content-Disposition'] === 'attachment' )

while trying to pull composer civicrm-core i get:
civicrm/civicrm-core 5.12.x-dev requires zetacomponents/mail dev-1.7-civi -> no matching package found

The module zetacomponets/mail can not be used without having also loaded zetacomponents/base, but does not have a requires section in its composer.json file listing this dependency. This means that a project that lists zetacomponents/mail as a dependency may error out unless it also adds zetacomponen/base as a dependency. This goes against the philosophy of composer where every module is supposed to declare all of its requirements so that composer can make sure they are all met.

The message is
Notice: iconv(): Detected an illegal character in input string in C:\inetpub\wwwroot\common_libs\vendor\zetacomponents\mail\src\internal\charset_convert.php on line 143

Than the text part returns empty
I see the original charset is utf8 and the output is utf8 then i made an if before iconv
if($originalCharset=='utf-8')return $text;

Atached is the email that causes the error, i read it from gmail
mail.txt

I think I understand the logic behind marking an email as read when you fetch it, but how can I avoid that?

I have seen in the examples that we can use top to get the X first characters of the email, but I would like to get it whole. Is that possible?

The only workaround I can see is fetch all emails, and then manually re-flag them as "unread". But if I fetch an already "read" email, I will mark it "unread", which is wrong.

Any solution?

Thanks!

PHP 7.3 upgrade PCRE to PCRE 2, causing it to be more strict with character ranges. There are two instances of regex which throw the following error in PHP 7.3: "Compilation failed: invalid range in character class at offset 5"

Found an issue with the imap transport, mailbox names with spaces are not quoted properly in the append() method of imap_transport.php which causes an error when appending a message to a mailbox:

According to RFC3501, Mailbox Naming (5.1):

Any character which is one of the atom-specials (see the Formal Syntax) will require that the mailbox name be represented as a quoted string or literal.

That includes a space:

atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards / quoted-specials / resp-specials

so, the right mailbox string should be:

"INBOX.folder with spaces"

I changed the {$mailbox} variables to \"{$mailbox}\" in the append() method in imap_transport.php and it works now.

If the HTML Mime Part will include image tags like

<pre>
<img src="myimage.jpg">
</pre>

the Mail Component willl woirk correctly.

If there is a image tag with more attributes after the src attribute the PCRE will fail to get the correct file path.

<pre>
<img src="myimage.jpg" extraattribute="test">
</pre>

Some linux systems have no support for this encoding, but emails with it is still present. For example, the Hotmail mail delivery daemon report emails. Message parsing become broken with PHP Notice:

iconv(): Wrong charset, conversion from unicode-1-1-utf-7' toutf-8' is not allowed`

I suggest to add the hardcoded alias to the ezcMailCharsetConverter::convertToUTF8Iconv() method:

    if ( $originalCharset === 'unknown-8bit' || $originalCharset === 'x-user-defined' )
    {
        $originalCharset = "latin1";
    } 
    elseif ( $originalCharset === 'unicode-1-1-utf-7')
    {
        $originalCharset = "utf7";
    }

Hi,
How to use Zeta Mail Component in Laravel project 5.x? What should I do?

Thanks

Hi

v1.8.1 has been tagged recently, but this version has not been synced on Packagist (see ZetaComponents Mail page on Packagist.

Is the hook set on this repository?
At least a "force refresh" on Packagist page should fix it.

Thanks

The create_function() function is used in src/tools.php:

It is deprecated in PHP 7.2:
http://php.net/manual/en/migration72.deprecated.php#migration72.deprecated.create_function-function

I couldn't find anything in the eczMail class relating to this, and I've been searching the doc and the issues for this but can't find anything.

Also, any way to mark it read/unread?

Thanks

Please support StartTLS for IMAP (and POP).

Is there any documentation to this?
Maybe add a Readme, Wiki and/or link to the website for this Repo.

Thank you. I am sure this is a great library 👍

Some fixes have gone in since the last tag , so might be time for a new one here.

I believe that the lines 224 and 225 in imap_set.php should be swapped as otherwise there is a case in which $data will be returned althought it is not set.

public function getNextLine()
{
if ( $this->hasMoreMailData )
{
if ( $this->bytesToRead !== false && $this->bytesToRead >= 0 )
{
$data = $this->connection->getLine(); // <- $data is set here
$this->bytesToRead -= strlen( $data );
if ( $this->bytesToRead <= 0 )
{
...
return $data;
}
}
return $data; // <- $data is returned outside of if although it might not be set
}
return null;
}

I believe return $data; should be inside of if statement.

I try to send an email using SMTP with tls connection, but receive this error.
FYI, I'm using Mailgun server.

telnet smtp.mailgun.org 587
Trying 50.56.21.178...
Connected to smtp.mailgun.org.
Escape character is '^]'.
220 ak47 ESMTP ready
ehlo blog.mailgun.com
250-ak47
250-AUTH PLAIN LOGIN
250-SIZE 52428800
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 STARTTLS

After some checking, the cause is

<?php 

...

if ( !preg_match( "/250-STARTTLS/", $response) )
{
    throw new ezcMailTransportSmtpException( 'SMTP server does not accept the STARTTLS command.' );
}

in https://github.com/zetacomponents/Mail/blob/master/src/transports/smtp/smtp_transport.php#L618

It match 250-STARTTLS but not 250 STARTTLS

The problem seems to be Mail/src/transports/imap/imap_transport.php in the listMessages function, which searches (using a wildcard) for all messages in the inbox, and then sends a request to fetch the size of all the messages by passing the ids of all the messages returned in the search. This results in an IMAP command that exceeds the 16K limit set by courier.

This problem was originally reported against CiviCRM (https://issues.civicrm.org/jira/browse/CRM-15499) and is explained by the courier developers here: http://markmail.org/message/63n2ukjznkcqsit7#query:+page:1+mid:j4x2z7j4ymytvjbf+state:results

I think the solution (as documented on the CiviCRM ticket) is to limit the results of the wildcard search to a batch limit that can be set by the user and defaults to a more reasonable size.

Hi,

I had to replace this line:

By this line:

$tmpValue = false;

For some reason, I had a PHP timeout, even with 180 seconds.

ezcMailCharsetConverter::convertToUTF8Iconv()

Notice: iconv(): Detected an illegal character in input string
vendor/zetacomponents/mail/src/internal/charset_convert.php on line 143

This message causes the problem.

Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Alexander Ashmore �

Some servers, particularly Exchange 2013+ and O365, have TLS protocol enabled on port 143, rather than and/or in addition to SSL on 993. TLS seems to require a few specific steps, especially on Exchange/O365 boxes. From what I can gather, a successful connection to port 143 needs to be made, then the connection needs to be upgraded to an encrypted connection, then STARTTLS needs to be issued, then authentication needs to happen. (I won't guarantee that order, but that seems to be the steps.) I guess in a perfect world, there would be a new is_tls routine and checkbox. The is_tls routine would be called straight away when set, but if it's unset it could also attemp the is_tls routine when a non-encrypted connection is established for an "auto" type setting.

Please declare dependencies in the "require" feature of your composer.json file. This Mail package depends on zetacomponents/Base. This requirement is undeclared in the composer.json file, and therefore will not run properly if someone requires the zetacomponents/Mail package alone.

Path for attachments is created as decoded string. So for some cases with long UTF8 filenames it can exceed OS limitation for 255 symbols and attachment can't be moved from /tmp to target directory.