ddeboer / imap

Object-oriented, fully tested PHP IMAP library
MIT License
889 stars 252 forks source link

testing to see if replyTo header is present? #398

Open terrafrost opened 5 years ago

terrafrost commented 5 years ago

I'm trying to import a bunch of emails and would like to make it so that the "From" address that gets stored in the DB is either the "From" address in the email or, if present, the "Reply-To" address.

To that end I started looking at $message->getHeaders()->get('reply_to'). So an email I found that did have the Reply-To header set had the following data in it:

array(1) {
  [0]=>
  object(stdClass)#1034 (3) {
    ["personal"]=>
    string(16) "user@website.com"
    ["mailbox"]=>
    string(4) "user"
    ["host"]=>
    string(11) "website.com"
  }
}

The problem is... apparently I get an stdClass object even when the Reply-To is not set. The only real difference that I can discern is that the personal variable isn't a valid email address when Reply-To isn't set (the fact that it's not set makes me think it's being derived from the "From" email or something). ie. it looks like this:

array(1) {
  [0]=>
  object(stdClass)#1034 (3) {
    ["personal"]=>
    string(9) "Full Name"
    ["mailbox"]=>
    string(4) "user"
    ["host"]=>
    string(11) "website.com"
  }
}

What I'd expect is for $message->getHeaders()->get('reply_to') to return NULL or maybe an empty array when "Reply To" wasn't set but that's not what's happening.

My question is... how can I test to see if the Reply-To header is present since apparently the above technique doesn't work?

Thanks!

edit: like in one such email that doesn't have a Reply-To header... "reply-to" occurs exactly four times in the headers. Once in the ARC-Message-Signature header, once in the DKIM-Signature-Header, once in the X-Google-DKIM-Signature header and once as a substring of the "In-Reply-To" header. But "Reply-To", by itself, does not appear anywhere.

FWIW I'm running 0.5.2...

edit: it looks like this is still an issue on 1.6.0...

Slamdunk commented 5 years ago

I can confirm this bug of imap_headerinfo. The weird thing is that also imap_rfc822_parse_headers is affected:

$rawHeaders = $message->getRawHeaders();
var_dump($rawHeaders);
print_r(imap_rfc822_parse_headers($rawHeaders));

Output:

string(187) "From: from@there.com
To: to@here.com
Subject: Nuu
Date: Wed, 13 Sep 2017 13:05:45 +0200
Content-Type: text/plain;
    charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

"
stdClass Object
(
    [date] => Wed, 13 Sep 2017 13:05:45 +0200
    [Date] => Wed, 13 Sep 2017 13:05:45 +0200
    [subject] => Nuu
    [Subject] => Nuu
    [toaddress] => to@here.com
    [to] => Array
        (
            [0] => stdClass Object
                (
                    [mailbox] => to
                    [host] => here.com
                )

        )

    [fromaddress] => from@there.com
    [from] => Array
        (
            [0] => stdClass Object
                (
                    [mailbox] => from
                    [host] => there.com
                )

        )

    [reply_toaddress] => from@there.com
    [reply_to] => Array
        (
            [0] => stdClass Object
                (
                    [mailbox] => from
                    [host] => there.com
                )

        )

    [senderaddress] => from@there.com
    [sender] => Array
        (
            [0] => stdClass Object
                (
                    [mailbox] => from
                    [host] => there.com
                )

        )
)

So at the time of writing there is no built-in solution for this bug.

Definitively we should move out of imap extension