If you use the iterator, the key of the current element is the local name. Name from the root folder (including delimiters), the local name is the name in the parent folder. Global name returned by the methods getLocalName() and getGlobalName(). Each of these instances has a local and a It’s returned as an instance of Zend\Mail\Storage\Folder, which implements RecursiveIteratorĪnd all children are also instances of Zend\Mail\Storage\Folder. With the method getFolders($root = null) you can get the folder hierarchy starting with the root folder or the This header specifies that this body part is to be treated as a file and saved on local storage under the suggested file name (instead of being displayed to the user).// mbox with folders $mail = new Zend\Mail\Storage\Folder\Mbox ( array ( 'dirname' => '/home/test/mail/' )) // mbox with a default folder not called INBOX, also works // with Zend\Mail\Storage\Folder\Maildir and Zend\Mail\Storage\Imap $mail = new Zend\Mail\Storage\Folder\Mbox ( array ( 'dirname' => '/home/test/mail/', 'folder' => 'Archive' )) // maildir with folders $mail = new Zend\Mail\Storage\Folder\Maildir ( array ( 'dirname' => '/home/test/mail/' )) // maildir with colon as delimiter, as suggested in Maildir++ $mail = new Zend\Mail\Storage\Folder\Maildir ( array ( 'dirname' => '/home/test/mail/', 'delim' => ':' )) // imap is the same with and without folders $mail = new Zend\Mail\Storage\Imap ( array ( 'host' => '', 'user' => 'test', 'password' => 'test' )) The "Content-Disposition: attachment" header has a parameter, "filename=", which specifies a suggested name for the file. Because the file attachment is an ASCII text file, it is sent with no encoding and its content-type is given as text/plain. The second body part in this example contains the file attachment. Its single "Content-Type:" header identifies it as "text/plain", meaning US-ASCII characters are used exclusively and any UA should be able to display this body part. The first body part is a plain text message, the message the sender might have typed into a UA. If there were no headers in the body parts, then the blank line that must follow headers in RFC 822 messages would follow the boundary string. Each body part begins with the boundary string. Each body part has headers of its own, in addition to the overall message headers. There are two message body parts in the preceding example. If the example had encoded parts, they would make no sense to the human reader using a non-MIME-compliant UA, but at least the courtesy message would give the user a hint as to why not. A UA that does not support MIME will display it, and at least this part of the message will be readable no matter what features the UA supports. In the preceding example, the courtesy message " This is a multipart message in MIME format." will not be displayed or otherwise processed by the MIME UA because it does not follow a " boundary=" string. The final body part is followed by the " boundary=" string with the " -" both prepended and appended. The actual boundaries are constructed using the " boundary=" string, prepended by " -".
A MIME-compliant UA will only display or otherwise process content following the specified " boundary=" text strings. This tells the receiving UA that this message has parts separated by the string argument defined in " boundary=". The " Content-Type:" header specifies "multipart/mixed". The " MIME-Version:" header tells the receiving UA to treat this as a MIME message.
This is a multipart message in MIME format.
0 kommentar(er)
