note 129893 added to function.imap-mail-move
| From: | jab_creations@yahoo.com | Date: | Wed, 04 Dec 2024 04:27:41 +0000 |
| Subject: | note 129893 added to function.imap-mail-move | ||
| Groups: | php.notes | ||
| Request: | Send a blank email to php-notes+get-221696@lists.php.net to get a copy of this message | ||
The imap_mail_move() function's second parameter (message_nums parameter) accept two valid
values:
Individual message number:
47
or
Array:
47,58,112
Remember four key things in combination!
1. This move function does not move anything, internally it creates a copy and then deletes the
original!
2. You should be tracking the Message-Id header (that should be set!) internally to confirm the
unique IMAP id.
3. Because when a message is pseudo-"moved" the original message and unique IMAP id are
lost! That means after the internal copy (or to us, having been moved) is created you will then have
to create a new connection to the second mailbox folder, list or search and verify by internal
message identifiers to keep your mail shell synchronized with the external server. Which then in
turn means...
4. You will have to track the copied message after it is destroyed in the first mailbox folder. That
gives you two logical approaches to use:
4.1 Individually move the message then simply get an index of the destination folder (e.g. moving
from inbox to trash), "move" the message using this command, getting the index of the
trash mailbox folder and comparing the arrays to determine the oddball out.
4.2 But in reality we're moving multiple messages in a single go so you can scan the mailbox
folder for each message however this presumes that the header (e.g. Message-Id) exists.
Example search:
$result = imap_search($mail_connection_folder_trash, "TEXT
\"<24322757.12578452.2416351620568@domain.tld>\"", SE_UID);
In my limited experience of a few thousand emails only spammers or devastatingly underpaid
developers have not set the Message-Id. You can not presume however that the missing header implies
spam as my original system never set it. Hence why it may be necessary to search by a secondary or
tertiary means in more non-common scenarios with oddball messages. This may occur in one-in-several
thousand instances.
Hopefully this logic will spare a few people the time spent on conceptual work.
----
Server IP: 45.112.84.4
Probable Submitter: 45.112.84.18 (proxied: 149.22.94.93)
----
Manual Page -- https://php.net/manual/en/function.imap-mail-move.php
Edit -- https://main.php.net/note/edit/129893
Del: integrated -- https://main.php.net/note/delete/129893/integrated
Del: useless -- https://main.php.net/note/delete/129893/useless
Del: bad code -- https://main.php.net/note/delete/129893/bad+code
Del: spam -- https://main.php.net/note/delete/129893/spam
Del: non-english -- https://main.php.net/note/delete/129893/non-english
Del: in docs -- https://main.php.net/note/delete/129893/in+docs
Del: other reasons-- https://main.php.net/note/delete/129893
Reject -- https://main.php.net/note/reject/129893
Search -- https://main.php.net/manage/user-notes.php