在Web应用程序中发送电子邮件 [英] Sending emails in web applications

问题描述

我正在寻找一些意见，我正在构建一个具有相当标准功能的网络应用程序：

1. 注册


2. 收到一封确认代码链接的电子邮件


3. 点击链接确认新帐号并登录

当您从Web应用程序发送电子邮件时，往往（通常）会出现以下情况：持久层例如：

1. 新用户注册您网站上的一个帐户 - 新用户在数据库中创建，电子邮件发送到他们与确认链接


2. 用户向其他人分配错误或问题 - 更新问题并发送电子邮件通知。

如何发送这些电子邮件对您的应用程序的成功至关重要。您如何发送这些信息取决于收件人收到的电子邮件的重要性。

我们将关注以下四种策略：邮件服务器关闭，使用示例1。

TRANSACTIONAL& SYNCHRONOUS
发送电子邮件失败，用户显示一条错误消息，表示无法创建其帐户。当应用程序等待连接超时时，应用程序将显得缓慢而无响应。该帐户不会在数据库中创建，因为该事务被回滚。

TRANSACTIONAL& ASYNCHRONOUS
这里的事务定义是指将电子邮件发送到JMS队列或将其保存在数据库表中以供另一个后台进程选择和发送。

用户帐户是在数据库中创建的，电子邮件将发送到JMS队列以供稍后处理。交易成功并承诺。用户显示一条消息，指出他们的帐户是创建的，并检查他们的电子邮件确认链接。在这种情况下，由于某些其他错误，电子邮件永远不会发送，但是用户被告知该电子邮件已发送给他们。如果需要调用应用程序支持来诊断电子邮件问题，可能会有一些延迟将电子邮件发送给用户。

非事务性SYNCHRONOUS
用户是在数据库中创建的，但是当尝试使用确认链接发送电子邮件时，应用程序会收到超时错误。用户显示一条错误消息，指出有错误。应用程序缓慢而无响应，因为它等待连接超时。

当邮件服务器恢复生效，用户尝试重新注册时，他们被告知他们的帐户存在，但尚未确认，并可选择将电子邮件重新发送给他们。

非交易性& ASYNCHRONOUS
这个和事务&异步的是，如果将电子邮件发送到JMS队列或将其保存在数据库中，则仍然创建用户帐户，但是在用户尝试重新注册之前，永远不会发送电子邮件。

我想知道的是其他人在这里做什么？你可以推荐除上述4之外的任何其他解决方案吗？接近这个问题的合理方法是什么？我不想过度设计一个处理我的邮件服务器的（希望）罕见情况的系统！

最简单的事情是同步编码，但这种方法还有其他的陷阱吗？我想我想知道是否有最佳做法，我无法通过谷歌搜索找到很多东西。

解决方案

我的2美分：

1. 一旦您有用户注册，如果发送电子邮件失败，则不要退回注册。出于简单的商业原因：如果第一次尝试不起作用，他们可能不会回来或重新注册。相反，容忍不完整的注册，并且使用户尽快确认他们的电子邮件地址。




2. 在大多数情况下，发送电子邮件时出错，您的应用程序将无法立即得到反馈 - 有效服务器上的不存在的电子邮件地址将发送一段延迟的不可投递消息;如果邮件被垃圾邮件过滤器吃掉，您根本不会收到任何反馈;在其他情况下，可能需要几分钟（灰名单）几天（邮件服务器暂时关闭）才能发送电子邮件。因此，等待邮递的同步方法注定是IMO。即使是立即失败（因为用户输入了一个明显的假地址）应该永远不会导致注册回滚。

我会做的是使帐户创建尽可能简单，允许用户访问之前的帐户，这是确认的，然后将它们从他们中删除确认他们的电子邮件（如有必要，限制访问某些区域，直到确认）。尽管如此，我会阻止创建具有相同电子邮件的第二个帐户，以防止混乱。

确保您允许更改电子邮件地址，即使以前的地址尚未确认，并允许用户重新请求确认消息到不同地址。

I'm looking for some opinions here, I'm building a web application which has the fairly standard functionality of:

1. Register for an account by filling out a form and submitting it.
2. Receive an email with a confirmation code link
3. Click the link to confirm the new account and log in

When you send emails from your web application, it's often (usually) the case that there will be some change to the persistence layer. For example:

1. A new user registers for an account on your site - the new user is created in the database and an email is sent to them with a confirmation link
2. A user assigns a bug or issue to someone else - the issue is updated and email notifications are sent.

How you send these emails can be critical to the success of your application. How you send them depends on how important it is that the intended recipient receives the email.

We'll look at the following four strategies in relation to the case where the mail server is down, using example 1.

TRANSACTIONAL & SYNCHRONOUS The sending of the email fails and the user is shown an error message saying that their account could not be created. The application will appear to be slow and unresponsive as the application waits for the connection timeout. The account is not created in the database because the transaction is rolled back.

TRANSACTIONAL & ASYNCHRONOUS The transactional definition here refers to sending the email to a JMS queue or saving it in a database table for another background process to pick up and send.

The user account is created in the database, the email is sent to a JMS queue for processing later. The transaction is successful and committed. The user is shown a message saying that their account was created and to check their email for a confirmation link. It's possible in this case that the email is never sent due to some other error, however the user is told that the email has been sent to them. There may be some delay in getting the email sent to the user if application support has to be called in to diagnose the email problem.

NON-TRANSACTIONAL & SYNCHRONOUS The user is created in the database, but the application gets a timeout error when it tries to send the email with the confirmation link. The user is shown an error message saying that there was an error. The application is slow and unresponsive as it waits for the connection timeout

When the mail server comes back to life and the user tries to register again, they are told their account already exists but has not been confirmed and are given the option of having the email re-sent to them.

NON-TRANSACTIONAL & ASYNCHRONOUS The only difference between this and transactional & asynchronous is that if there is an error sending the email to the JMS queue or saving it in the database, the user account is still created but the email is never sent until the user attempts to register again.

What I'd like to know is what have other people done here? Can you recommend any other solutions other than the 4 I've mentioned above? What's a reasonable way of approaching this problem? I don't want to over-engineer a system that's dealing with the (hopefully) rare situation where my mail server goes down!

The simplest thing to do is to code it synchronously, but are there any other pitfalls to this approach? I guess I'm wondering if there's a best practice, I couldn't find much out there by googling.

解决方案

My 2 cents:

1. Once you have a user sign up, never roll back the registration if sending the E-Mail fails. For simple business reasons: They may not come back or re-register if it doesn't work out at the first try. Rather tolerate an incomplete registration and nag the user to confirm their E-Mail address as soon as possible.

2. In most cases when sending an E-Mail goes wrong, your app will not get immediate feedback anyway - non-existent E-Mail addresses on valid servers will send back a "undeliverable" message with some delay; if the mail gets eaten by a spam filter, you'll get no feedback at all; in other scenarios, it may take several minutes (greylisting) to several days (mail server temporarily down) for an E-Mail to get delivered. A synchronous approach waiting for the delivery of the mail is therefore doomed IMO. Even an immediate failure (because the user entered a obviously fake address) should never result in the registration getting rolled back.

What I would do is, make account creation as easy as possible, allow the user access to the account before it is confirmed, and then nag the hell out of them to confirm their E-Mail (if necessary, limit access to certain areas until confirmation). I would prevent the creation of a second account with the same E-Mail, though, to prevent clutter.

Make sure you allow changing the E-Mail address even if the previous address hasn't been confirmed yet, and enable the user to re-request the confirmation message to a different address.

这篇关于在Web应用程序中发送电子邮件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！