sendmail - удостоверьтесь, что электронное письмо послано
Amazon Свободный Уровень Использования - Работы http://aws.amazon.com/free/ хорошо для Вашей цели!
После некоторого исследования я обнаружил, что сообщение в скобках (В очереди! 1360512372 qp 15149 < 201302101604.r1AG4Q0V027910@mail.nnn.se >) является сообщением с принимающего сервера.
это означает:
- да, письмо отправлено.
- нет, так как сообщение поставлено в очередь на принимающем сервере.
Вот некоторые объяснения того, как я мог получить свой ответ: Статус журнала почты freebsd 8, что это значит? некоторые цитаты из ответа, который мне показался надежным:
«Запись состояния отправлено означает, что удаленный сервер принял сообщение».
«Комментарии в скобках записи состояния - это ответ, предоставленный удаленным сервером. при отправке электронного письма. Это полезно для того, чтобы узнать, почему сообщение было отклонено, отложено или задержано »
Зачем вам это менять? Именно так и должен работать sendmail. Sendmail, прежде чем подтвердить исходному отправителю, что он принял почту, сохраняет ее в очереди на жестком диске. Затем он забирает его и хранит физическую копию до тех пор, пока следующий получатель не подтвердит получение. Таким образом sendmail гарантирует, что почта не будет потеряна в случае серьезного сбоя системы или самого sendmail. Sendmail также задерживает почту по разным причинам. Иногда другие MTA, которые вы не контролируете, задерживают электронную почту (проблемы с сетью, загрузка системы, серый список). Ему необходимо где-то безопасно хранить почту.
Электронная почта НЕ является механизмом своевременной доставки, как IM. В обычных условиях подождите 2 секунды.
Вы узнаете, что оно отправлено, когда видите другой почтовый сервер с stat = Sent: relay = mail1.someone.com. [207.106.200.39], dsn = 2.0.0, stat = Sent
SMTP does not guarantee that the email will reach its destination; it's a best-effort delivery mechanism with no synchronous end-to-end feedback about the fate of your traffic. The server to which you are delivering mails must directly tell you whether it is accepting them for eventual delivery, but it needn't deliver them synchronously (it can store them for later and not tell you), and it needn't deliver them directly (the path has multiple hops). In practice, nearly all SMTP daemons queue mails.
Delivery and read receipts, which are not widely supported due to their abuse by spammers, were designed to overcome this limitation. Additionally, servers later down the line may, at their option, at some future time, send you a notification if they reject your message after the initial server to which you passed it accepted it, but are not required to.
Your application should treat the next hop's acceptance as a success case. This is the most reliable feedback SMTP will consistently give you.