Сделай Сам Свою Работу на 5

Альтернативные способы отправки писем





 

На сегодняшний день распространены следующие способы отправки писем из php-скриптов:

· Посредством вызова функции mail.

· Непосредственно вызовом sendmail-а.

· При помощи сокетов.

· Используя COM-объект.

 

Первые три способа реализованы в классе PEAR::Mail, о котором было рассказано выше. Экземпляр этого класса должен создаваться посредством статического вызова метода factory (так называемый "паттерн фабрика"). Первый параметр метода определяет способ отправки письма, он может принимать одно из следующих значений: mail, sendmail, smtp. Второй параметр - массив, содержание которого зависит от значения первого параметра:

· Значение 'mail' - отправка при помощи вызова стандартной функции, дополнительные параметры отсутствуют.

· Значение 'sendmail' - отправка непосредственно вызовом sendmail-а. Доступные дополнительные параметры:

· sendmail_path - путь к программе на сервере;

· sendmail_args - дополнительные параметры для командной строки.

· Значение 'smtp' - отправка почты при помощи сокетов. Доступные дополнительные параметры:

· host - IP адрес или доменное имя сервера, на котором запущен почтовый транспортый агент, готовый принимать почту, например localhost (для локального сервера) или mxs.mail.ru (для публичного сервера);



· port - порт на котором он запущен, как правило 25-тый;

· auth - логическое значение, которое указывает на необходимость SMTP авторизации, значение по умолчанию - false;

· username - используется только при наличии SMTP авторизации, логин на сервере;

· password - используется только при наличии SMTP авторизации, пароль на сервере.

 

Пример использования класса PEAR::Mail (пример 9.4.1):

 

<?

$mail =& Mail::factory('smtp', array('host' => 'localhost', 'port' => 25));

$mail->send('postmaster@localhost', $hdrs, $body);

?>

 

Как настроить сервер для отправки почты

 

Как настроить Linux-сервер

 

Не стоит забывать, что отправка почты при помощи сокетов не требует установленного MTA (mail transfer agent), а позволяет использовать любой доступный для вас сервер, готовый принимать почту, к примеру, smtp.mail.ru.

Если у вас на экране появилось ошибка "Fatal error: Call to undefined function: mail()", это значит, что либо PHP собран без поддержки функции mail, либо она запрещена настройками сервера. Первое может возникнуть в том случае, если во время сборки скрипт configure не смог найти sendmail. Убедитесь, что путь к sendmail прописан в переменной окружения PATH, и попробуйте пересобрать PHP. Также посмотрите значение переменной disable_functions в файле php.ini.



В случае, если письма принимаются к отправке, но на этом все заканчивается, убедитесь в том, что у вас запущен Sendmail (либо любой другой MTA). Для этого попробуйте выполнить `telnet localhost 25` и если вы в ответ получаете "telnet: connect to address 127.0.0.1: Connection refused" вместо ожидаемого " Connected to localhost.", это означает, что у вас проблемы с MTA. Установка и настройка постовых транспортных агентов не описывается в данной статье, воспользуйтесь специализированными руководствами.

В случае, если попытка обратиться к 25-му порту прошла успешно, попробуйте провести следующий сеанс:

 

l72:~ # telnet localhost 25

Trying ::1...

telnet: connect to address ::1: Connection refused

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

220 utel.us ESMTP Sendmail /8.12.7/Linux 0.6; Wed, 22 Oct 2003 16:10:45 +0300

helo localhost

250 72.utel.us Hello localhost [127.0.0.1], pleased to meet you

mail from: nobody@localhost

250 2.1.0 nobody@localhost... Sender ok

rcpt to: nobody@localhost

250 2.1.5 nobody@localhost... Recipient ok

DATA

354 Enter mail, end with "." on a line by itself

Helo world

.

250 2.0.0 h9MDAj1B009029 Message accepted for delivery

quit

Connection closed by foreign host.

 

Приведенный пример демонстрирует успешный сеанс отправки письма. В случае возникновения ошибок (например, требуется корректный адрес отправителя в строке "mail from"), sendmail выдаст предупреждение, и попросит повторить введенную строку.

Если с командной строки письма успешно отправляются, а при помощи php нет, попробуйте поэкспериментировать с четвертым параметром функции mail либо с настройкой sendmail_path, находящейся в файле php.ini



 

Как настроить Windows-сервер

 

Вначале необходимо определится, какой SMTP-сервер вы хотите использовать. Это может быть как ваш персональный PC, так и любой другой. Какой бы способ вы не выбрали, вам необходимо установить переменные SMTP, smtp_port, определяющие настройки сервера, отправляющего почту. Также установите переменную sendmail_from, определяющую обратный адрес отправителя.

Дальнейшее инструкции относятся только к тем, кто решил использовать свой персональный PC как сервер исходящей почты.

Проверьте, отвечает ли кто-либо на 25-м порту. Это можно сделать, выполнив `telnet localhost 25`. Если вы получили "Connection refused", это означает, что у вас не запущен почтовый агент, и, вероятнее всего, не установлен. В таком случае вам необходимо посетить один из следующих ресурсов:

· http://www.argosoft.com/applications/mailserver/

· http://courierms.narod.ru/

· http://www.indigostar.com/sendmail.htm

 

Выберите программу, отвечающую вашим потребностям, и далее следуйте инструкциям по её установке и применению.

 

Как сделать WEB-доступ к почте

 

Посетите один из следующих ресурсов:

· http://www.squirrelmail.org/

· http://www.horde.org/

 

На любом из них вы найдете все необходимые скрипты и детальную инструкцию по инсталляции и настройке.

 

Описание MIME

 

Более подробно о MIME вы можете прочитать тут http://book.itep.ru/4/4/mime.htm.

Изначально, когда почта только зарождалась, никакого MIME не существовало. Он появился несколько позже как расширение к стандарту RFC-822. В настоящее время любое отправленное письмо, даже если оно не содержит никаких вложений, так или иначе использует MIME.

Вначале письмо понималось как линейное текстовое послание, содержимое которого можно прочитать, просмотрев его исходный код. Расширение MIME позволяет определить внутри письма специфические атрибуты: тип передаваемой информации, способ его кодирования и рекомендации к отображению. Также позволяет разбивать письмо на независимые секции и выставлять индивидуальные атрибуты для каждой из них.

Чтобы наглядно показать разницу, рассмотрим два примера, содержащие одно и то же письмо в двух различных представлениях: обыкновенное письмо по стандарту RFC-822 и то же письмо, но с использованием MIME

 

From: "John Coggeshall" <john@zend.com>

To: Joe Users <joe@user.net>

Subject: Hello from John!

Date: Wed, 20 Jun 2001 20:18:47 -0400

Message-ID: <1234@local.machine.example>

Наше вам с кисточкой!

 

From: "John Coggeshall" <john@zend.com>

To: Joe Users <joe@user.net>

Subject: Hello from John!

Date: Wed, 20 Jun 2001 20:18:47 -0400

Message-ID: <1234@local.machine.example>

MIME-Version: 1.0

Content-Type: text/plain; charset="iso-8859-1"

Content-Transfer-Encoding: 7bit

Наше вам с кисточкой!

 

Разница в приведенных письмах очевидна: во втором примере используются три дополнительных заголовка. Обязательным из них является только первый: MIME-Version. Наибольший интерес для нас представляет заголовок Content-Type, изменяя который мы можем передавать произвольные типы документов.

 

From: "John Coggeshall" <john@zend.com>

To: Joe Users <joe@user.net>

Subject: Hello from John!

Date: Wed, 20 Jun 2001 20:18:47 -0400

Message-ID: <000d01c0f9e7$bee1bb00$8a22f340@oemcomputer>

MIME-Version: 1.0

Content-Type: image/jpeg; name='zendlogo.jpg'

Content-Transfer-Encoding: base64

<base64 encoded data for the zendlogo.jpg image>

 

Сами данные base64 в примере были опущены. Недостаток приведенного примера – невозможность вставить текстовую часть, так как все нижеследующие данные трактуются как данные рисунка.

Если у вас возникает задача отправить несколько различных объектов в одном письме (к примеру, текстовая часть и прикрепленная картинка) необходимо использовать заголовок Content-Type:multipart/mixed, обозначающий, что письмо состоит из нескольких сегментов. Так же необходимо определить параметр boundary, который будет обозначать границу между фрагментами. В преобладающем большинстве случаев его реальное значение можно выбирать произвольно. Каждый фрагмент комплектуется отдельным набором заголовков. Заметим, что заголовок MIME-Version должен быть один на все письмо и не может встречаться ни в одной из его частей. Приведем пример письма, состоящего их двух частей: текстового сообщения и прикрепленного изображения:

 

From: "John Coggeshall" <john@zend.com>

To: Joe Users <joe@user.net>

Subject: Hello from John!

Date: Wed, 20 Jun 2001 20:18:47 -0400

Message-ID: <000d01c0f9e7$bee1bb00$8a22f340@oemcomputer>

MIME-Version: 1.0

Content-Type: multipart/mixed; boundary="ZEND-12345";

Content-Transfer-Encoding: 7bit

This part of the E-mail should never be seen. If

you are reading this, consider upgrading your e-mail

client to a MIME-compatible client.

--ZEND-12345

Content-Type: text/plain; charset="iso-8859-1"

Content-Transfer-Encoding: 7bit

Hello! Here's that Zend.com logo!

-John

--ZEND-12345

Content-Type: image/jpeg; name="zendlogo.jpg";

Content-Transfer-Encoding: base64

Content-Disposition: attachment

 

--ZEND-12345--

 

Это простейший пример MIME-письма, состоящего из нескольких частей. Первая из них имеет тип text/plain и содержит реальное содержание письма. Вторая часть имеет тип image/jpeg и содержит закодированную base64 картинку, с названием zendlogo.jpg

При использовании составного письма, следует помнить:

· Первичный заголовок content-type имеет значение multipart/mixed. Он сообщает клиентской почтовой программе, что письмо состоит из нескольких сегментов, каждый из которых имеет свой заголовок content-type.

· Значение атрибута boundary определенного в первичном заголовке content-type используется для разделения сегментов письма (так называемый маркер границы).

 

При использовании атрибута boundary постарайтесь, чтобы он был максимально уникален и не встречался в теле самого письма, так как в противном случае письмо будет неправильно разбито на составляющие части. Кроме того, маркер границы должен начинаться с двух дефисов, а в последнем своем вхождении, заканчивая письмо, он также заканчивается двумя дефисами. Заголовку, содержащему атрибут boundary, должны предшествовать два перевода строк, а последний маркер, означающий конец MIME-письма, должен также заканчиваться двумя переводами строк.

Второй сегмент письма содержит дополнительный заголовок Content-Disposition. Он используется для того, чтобы сообщить почтовой программе клиента, как визуально следует отобразить данный сегмент письма. Он может принимать значение как attachment (не является частью письма, прикрепленный документ), так и inline (включение, непосредственно связанное с телом письма, например картинка, вставленная в HTML). Также допустимо использование заголовка Content-Description для краткого описания прикрепленного файла.

Значение multipart/alternative атрибута Content-Type по синтаксису абсолютно идентично multipart/mixed, описанному выше. Его назначение – обеспечить несколько вариантов отображения одного и того же содержания (вместо соединения трех различных документов, как в предыдущем случае). Рассмотрим пример письма, отправленного в трех форматах:

 

From: "John Coggeshall" <john@zend.com>

To: Joe Users <joe@user.net>

Subject: Hello from John!

Date: Wed, 20 Jun 2001 20:18:47 -0400

Message-ID: <000d01c0f9e7$bee1bb00$8a22f340@oemcomputer>

MIME-Version: 1.0

Content-Type: multipart/alternative;

boundary="ZEND-12345";

Content-Transfer-Encoding: 7bit

This part of the E-mail should never be seen. If

you are reading this, consider upgrading your e-mail

client to a MIME-compatible client.

--ZEND-12345

Content-Type: text/plain; charset="iso-8859-1"

Content-Transfer-Encoding: 7bit

Hello! Here's that Zend.com!

-John

--ZEND-12345

Content-Type: text/enriched

<bold>Hello!</bold> Here is that <color><param>blue</param>Zend.com</color>!

-John

--ZEND-12345

Content-Type: application/x-myapplication

Content-Transfer-Encoding: base64

<base64 Content to display by the program that reads application/x-myapplication>

--ZEND-12345--

 

В приведенном письме содержатся три фрагмента. Первый их них содержит данные text/plain для отображения письма в виде текста. Второй фрагмент содержит те же данные в формате text/enriched (если вы хотите узнать подробней о формате, обратитесь к RFC 1896). Третий фрагмент содержит некий произвольный формат application/x-myapplication с base64 содержимым письма. Согласно с установленным заголовком multipart/alternative адресат увидит ту часть письма, которую его почтовый агент сможет отобразить визуально наилучшим образом. Это означает, что если пользователь имеет приложение, способное отобразить тип документа application/x-myapplication, тогда именно этот фрагмент будет показан пользователю. В противном случае будет произведена попытка отобразить тип text/enriched. И в случае неудачи будет отображена секция, содержащая письмо в формате text/plain.

Не случайно самый примитивный способ отображения письма был поставлен первым. Это сделано с учетом того, что почтовый клиент пользователя может не поддерживать формат MIME.

Очевидно, что заголовок multipart/alternative предоставляет возможность отправлять письма в формате text/plain и text/html одновременно, например:

 

From: "John Coggeshall" <john@zend.com>

To: Joe Users <joe@user.net>

Subject: Hello from John!

Date: Wed, 20 Jun 2001 20:18:47 -0400

Message-ID: <000d01c0f9e7$bee1bb00$8a22f340@oemcomputer>

MIME-Version: 1.0

Content-Type: multipart/alternative;

boundary="ZEND-12345";

Content-Transfer-Encoding: 7bit

This part of the E-mail should never be seen. If

you are reading this, consider upgrading your e-mail

client to a MIME-compatible client.

--ZEND-12345

Content-Type: text/plain; charset="iso-8859-1"

Content-Transfer-Encoding: 7bit

Hey, Joe!

I heard you wanted to know where my column was on website. Here's the address:

/zend/spotlight/index.php

-John

--ZEND-12345

Content-Type: text/html

Content-Transfer-Encoding: 7bit

Hey, Joe!

I heard you wanted to know where my column was on

<A HREF="http://www.zend.com/">Zend's</A> website.

Here's the address:

<A HREF=http://www.zend.com/zend/spotlight/index.php>Code Gallery</A>

-John

--ZEND-12345--

 

И в завершение несколько слов про отправку писем с внедренными изображениями. Существует несколько способов реализовать такую возможность. В секции, содержащей HTML-код можно написать следующее: <IMG SRC="http://www.zend.com/logo.jpg">. В случае, если в момент открытия такого письма пользователь находиться в on-line и данное действие не запрещено настройками его почтового клиента, содержимое картинки будет запрошено у сервера, и она будет отображена. Плюсом данного способа является малый размер отправляемого письма. Минусом – необходимость наличия on-line и зависимость от настроек почтового клиента. Второй способ – использовать заголовок Content-ID. Он используется для сопоставления каждой секции письма уникального идентификатора. В общем случае, такой заголовок может быть указан для каждой секции письма, но на практике это имеет смысл только если вам потребуется сослаться на этот фрагмент в теле письма либо в других фрагментах. Примером могут служить картинки, flash-анимации, ролики. И, таким образом, вы получаете возможность ссылаться не на внешний источник, а на секцию письма по ее идентификатору. Это выглядит так:

 

From: "John Coggeshall" <john@zend.com>

To: Joe Users <joe@user.net>

Subject: Hello from John!

Date: Wed, 20 Jun 2001 20:18:47 -0400

Message-ID: <000d01c0f9e7$bee1bb00$8a22f340@oemcomputer>

MIME-Version: 1.0

Content-Type: multipart/alternative;

boundary="ZEND-12345";

Content-Transfer-Encoding: 7bit

This part of the E-mail should never be seen. If

you are reading this, consider upgrading your e-mail

client to a MIME-compatible client.

--ZEND-12345

Content-Type: text/html

Content-Transfer-Encoding: 7bit

This is the zend logo:

<IMG SRC="cid:ZendImage12345">

--ZEND-12345

Content-Type: image/jpeg

Content-Transfer-Encoding: base64

Content-ID: ZendImage12345

<base64 encoded logo.jpg file>

--ZEND-12345--

 

Новизна этого примера в строке <IMG SRC="cid:ZendImage12345">, где внешний источник был заменен указанием локального идентификатора. Фактическое значение, указываемое в заголовке Content-ID, может быть произвольно, как и в случае с boundary. Главное требование – его уникальность в переделах письма. Используя такую методику прикрепления файлов, вы можете комплектовать полноценный пакет документов, таких, как html-содержимое письма, файлы стилей, картинки, офисные документы, текстовая версия, и отправлять его одним письмом. Правда, при этом не стоит забывать, что большинство пользователей имеют канал с малой пропускной способностью и, скорее всего, просто не захотят получать письмо большого размера.

 

 

 








Не нашли, что искали? Воспользуйтесь поиском по сайту:



©2015 - 2024 stydopedia.ru Все материалы защищены законодательством РФ.