Does it make sense to create a service whose only responsibility is to send emails for other services?
Let me try to express my doubts more clearly and give a little bit of context. BTW, you can ignore the term "SOA" if you like. My intent in including it was to communicate that I am talking about a distributed system that is partitioned by function.
The reasons why I am uncertain as to whether an "Email Service" is appropriate or not are:
It provides a technical function
rather than an organization
function. It doesn't compose the
email messages, it just processes
them. Would it make sense to have
the Email Service compose the
messages by responding to domain
events? Would this be beneficial or
harmful?
It seems to introduce dependencies
into all other services which
utilize it. Particularly, I can't
see how one could avoid RPCish
interactions between the client and
the Email Service. Even if you use
messaging, the messages would be of
the command style (telling the Email
Service to send an email) which as I
understand it are inappropriate for
communications between services
since they increase coupling due to
the knowledge the client has to have
about the service it is consuming in
order for it to tell it what to do.
Unless of course the Email Service
composes the messages in response to
domain events from other services
(see point 1).
It is questionable how much
"service" it provides. In other
words, isn't the SMTP server already
the "Email Service"? Of course, the
custom "Email Service" might provide
things like queuing and parsing of
delivery reports. How much and what
should be in the Email Service for
it to really be necessary?
The alternative would be to have each service within the organization be responsible for sending out it's own email messages. However, this would mean that each service would have to be dependent on the SMTP server, but is that any different from being dependent on a custom "Email Service"? It would also mean that each service would be responsible for queuing and delivery management. Is this beneficial or harmful?
In addition, the email messages are considered domain entities, meaning that the organization is interested in the messages themselves in addition to the events that initiated them and the information that they carried. This means that users will be interested in viewing the messages that were sent out within context. For example you might look at a customer's account and ask to view the messages that were sent to that customer (these messages might include: account created confirmation, order placed confirmation, order shipped notification, experience feedback request, etc.).
I apologize if my question makes certain assumptions or is unclear, but based on what I've written, can anyone suggest an approach or discuss an approach that they have taken and how it worked out? I've already looked around SO for similar questions and googled on the topic but did not find anything that really applied, but if anyone can point out any resources I would greatly appreciate it. I would also be interested in answers that point out things that I might be overlooking or misunderstanding. Any sort of discussion on the matter seems valuable to me.
It depends on the context. What is a service? Is it a technical resource or a business resource?
If you were working at a technical level, partitioning a large technical soluiton into smaller parts (separation of concerns, etc) then I'd agree that an email service might well fit into this.
If the services are business services (e.g: "customer credit check") then an email service wouldn't fit into this.
And of course there's no reason why you can have both: a "top" layer of business services, implemented by a (technical) solution (that is composed of various sub-systems and layers) which includes a collection of technical services.
Related
We are looking to develop a number of services, but are not sure which "response" mechanism is the best route to go. The two contenders are:
HTTP callbacks, where the service would update the client application via "pinging" it with update messages sent via HTTP requests
Message Passing, where the service would update the client via publishing messages into a pub-sub queue on a message server
In both cases, both the caller and the services are within our network, we have full control over them, and things we develop are the only users of the services.
What are the pros / cons of each way of providing status updates to the calling application, and what, if any, pros / cons would there be for making the initial request via one method or the other?
Note: The first service we have in mind for this is an email service similar to SendGrid, which we can't use for various reasons, but still need the same functionality.
The main difference would be the quality of service that you get "out of the box" with a messaging server.
If you go with HTTP then your application has to take care of what happens when a message doesn't arrive as expected. To get an idea of the issues you need to consider and the complexities involved in solving them, take a look at WS-ReliableMessaging or HTTPLR.
With messaging, you get a configurable level of reliability out of the box. And there's a lot of good choice these days such as ActiveMQ, RabbitMQ, 0MQ.
My personal preference is for reliability to be handled at the transport layer (by messaging), but then for a good discussion and dissenting view, check out "Nobody Needs Reliable Messaging."
I work for a company that builds embedded systems and we are currently developing a system for residential consumers, our primary focus until recently has been industrial and commercial applications.
One feature of this product is the ability for the device to send emails directly. The problem is the SMTP library is merely a client (as it should be) and thus requires configuring to connect to a mail server.
There is currently a debate going on as to whether we should be providing the mail server configuration information out of the box. At the moment the debate has split our team pretty much between the developers and management.
The developers think it will be too onerous for the "average" user to provide the FQDN or IP of the server, port, user, password and "from" address. Therefore, it would be preferable to only require the user's email address for the configuration to be complete.
Whereas management is worried about resource utilization (of course everyone is hoping for millions, or at least thousands, of users for our system!) and a "nefarious" user stealing the information we provide and using it for illicit purposes; while the developers don't think this is likely, as management pointed out, it would only take one spammer getting a hold of the account information and then we would be forced to shut it down for everyone.
The current compromise is to provide a unique email account for each device simple for relaying emails from our product to the user's email account. Obviously, this creates a management nightmare particularly because we are using a 3rd-party email hosting solution at the moment and can not automate the creation of these emails. Management does not like that fact that we have designed everything else to be automated and then throw in a nice big speed bump by manually creating each email account and then manually configuring each device to use this account.
Of course the developers suggested bring the email service in house but that creates other problems that we can not afford.
Which leads me to my question for the community, have you ever dealt with this problem? What solution did you decide upon? Why was that the best solution for you?
Since management is worried about a "nefarious" user free-riding your company's email service (besides that thought isn't that absurd) the only chance you have to not force people to go thru the hassle of configuration or to not burden you guys with manually creating accounts is to provide each client with a unique ID. This ID will allow you to shut down the service for the mallicous user.
One way to do this would be to configure each client to embed a unique ID in the header of every email. See this question. On the server side you would then have to implement a blacklist and check every email's header against it.
That's all, without further knowledge of your tech-stack it's impossible to provide a more detailed answer.
I'm using XMPP to drive a notification system. Basically I will have a set of services, some of which will broadcast to all users and some which are directed to a specific client (full JID).
For a service that broadcasts to all users a PubSub node seems the obvious choice but for a service that targets its messages to a specific client, I'm unsure of the best mechanism to use.
Do I represent these services as other client users and create bespoke implementations for them? The problem I see with this is how will they be discovered? Do I group them into a chat room and discover that. It feels like a bit of a hack. I could also define my own bespoke type of service, but then I have to define my own XML tags and maintain that.
I know there are plenty of standard extensions to XMPP but I cant see anything useful in this case.
Even in the pubsub case, the publisher (i.e. your service) is still a "user", so this configuration will be pretty standard. We simply create service accounts to represent those "users".
I am unsure of what you mean by "how will they be discovered". Why do the services need to be discovered? Your scenario only gives the use case of services sending messages to the users. Assuming the service already knows who the message is to be sent to, then you don't need any other information to send a message.
What are the risks, if any, of sending out massive amounts of emails over SMTP? Specifically, this question is regarding the risks of being labelled/blacklisted as spammers of spoofers.
Our mails are legitimate, however. Our system needs to send out reminders to our corporate users on a daily basis, which may number into the thousands, say. Our worry is that with such a setup, our domain might end up being blacklisted by the receiving organisation, thus rendering our reminder service useless.
Does anyone have any information on what might be a "safe" volume of emails to send out to avoid being blacklisted? Or can we just churn out emails with abandon?
You may be able to contract a third-party organization to take care of this for you. I know there's a lot of "direct marketing" companies that will let you use their API to send mass email (newsletters, etc). They can do the work of negotiating to get off blacklists - that's what you pay them for.
I haven't used Sendloop and don't know if it has the functionality you want, but it's probably a good example.
See: How to conduct legitimate email campaigns
In your reminder service, just follow some basic spam guidelines. Identify where the message came from, why the user got it, the link to "opt-out" or discontinue the reminders, and you'll be fine. Any blacklists you do get on will certainly remove you if you have this information in your messages.
Additionally, should you get blacklisted for some reason, have another server on a different network that you can use as a backup should your primary server get blacklisted temporarily for any reason.
Oh, and one final note - usually your entire "domain" (i.e. whatever.com) doesn't get blacklisted. Specific IP addresses or specific servers are usually what get blacklisted.
As long as you're mailing over clean IPs and domains you should be fine. You say your mailings are "legitimate" so there's no reason to worry about ISPs blocking you.
However, as you also mentioned, the volume can become a challenge. Broadly speaking, sending "thousands" of messages should be a non-issue. But... hundreds of thousands, say 250K messages a day on up, is when you start to qualify as a "high-volume" sender.
Once you start sending at this bulk level, you must run a tight ship. ISP filters will look for any clue that you're a black-hat mailer/spammer and will promptly block your deployment if anything looks off.
Make sure your list(s) are spic-and-span; all bounces, duplicates, typos and honey-pots have been scrubbed-out. Your IPs have been properly warmed-up, your DNS and domains are clean and properly registered and you remain responsive to your list recipients.
Basic common sense and following through on all the tiny, simple but crucial details goes a long way.
I'm implementing a email newsletter sender service using .NET and Windows Server technologies. Are there comprehensive guidelines which could help avoiding emails being trapped by spam filters and other mechanisms?
They should cover all aspects of (legal) bulk mail sending: SMTP configuration, DNS, HTML content, images, links within content etc. A simple example: is it better to embed images or load them from a server?
It would be great if you could provide some empirical data to show the efficiency of some measures taken.
Although I don't have a definitive answer, I think this is a very important question.
Here are few tidbits I know about it
Choose a clean hosting/smtp server. IP addresses of spamming SMTP servers are often black-listed by other ISPs.
Send a simple introductory email to every subscriber, asking them to add your sender address to their safe list.
Be very prudent in sending to only those people who are actually expecting it. You wouldn't want pattern recognizers of spam filters learning the smell of your content.
If you don't know your smtp servers in advance, its a good practice to provide configuration options in your application for controlling batch sizes and delay between batches. Some servers don't like large batches or continuous activity.
Unless you have a very specific reason to host the newsletter yourself, I think you'd be much better off using a third party service. There are lots out there, and some are very cheaply priced.
It'll save you on development work
(no point in re-inventing the
wheel).
Their system will handle all
the unsubscribe link stuff that you
need to include in email newsletters
to comply with CAN SPAM laws or
whatever.
They handle the spam
reports that you will inevitably get
if you have a list of any non-trivial size.
They keep records of who signed up,
how they signed up, and their IP
address, and can present those on
receipt of a spam report to prove
that their service wasn't sending
out spam.
You can use double-opt in
(or confirmed opt in), for extra
evidence to prove that the people
you're sending emails to actually
signed up to receive them.
If you really do need to host it yourself I'd suggest you search the web for "email deliverability". Things that are known to help include properly set up SPF records, DomainKeys/DKIM, correct DNS settings (reverse DNS especially - best to just use an online service to check your DNS settings). You can test a lot of these things by sending an email to check-auth#verifier.port25.com.
It's best to avoid using spammy words in your email - always a bit of guesswork this but you some words can trip filters.
But I'd guess that by far the most important thing is to be sending your email from a trusted server that maintains good relationships with ISPs (i.e. ensuring that ISPs don't think that the server is sending out spam). This is a big reason why it's much much easier to get a third party to handle everything for you.