Allowing mail delivery against a SQL db - email

My questions is regarding with MIMEDefang and I tried to reach their public mail list but after 1 week nobody accepted my join request. Also, I've already asked similar question to their mail list and i got no answer yet.
I'm trying to change the behavior of our Postfix mail server which is used for e-mail delivery to the customers. It doesn't accept any e-mails from the internet. A couple of weeks ago, the government decided to change mail delivery options for all banking industries. Basically the government add some some basic rules regarding with "gdpr" which should be applied for all outgoing mails to the banking customers. There is an options list to state customers desires about what kind of e-mails allowed to deliver their personal mail accounts. The mails could be 3 or 4 different types. For example, bills for payments, campaign mails, sending and receiving money receipts and so on. The policy says, if a customer specifically states that any of these mail types could send him, we can process it according his/her preferences. On the contrary, if a customer receives any mail other than its preferences the bank will face penalties for that behavior. I decided to use MIMEDefang to achieve this policy. The requirements listed above, drive me to use sql or redis service along with MIMEDefang because this list could change in time. I guess right on the "filter_recipient" time, I have to connect sql db to check whether the user allowed this mail to deliver its personal mail account. Is it possible to use sql (postgresql, mariadb,) with MIMEDefang ? I'm not certain about which callback is the right choice here to query that. May be "filter_end" is better than "filter_recipient" callback for this particular check because there is another condition which needs to check/determine the type of e-mail.
The second condition is the type of e-mail. I have to look at the contents in the DATA portion of e-mail and find out the type of e-mail. I'm going to tie these two conditions and decide to allow or drop e-mails individually. Also, there are 90K customers and we were delivered 30K mails per day at most.
I would like to ask some questions about SQL and MIMEDefang.
Is that possible to use SQL queries with MIMEDefang to validate recipients and its preferences ?
Is there any drawbacks while using SQL services with MIMEDefang ?
Where can i tie these conditions with each other ? Which callback is eligible to process these two conditions together ?

Related

How to exceed 10,000 Emails sent using Office 365

This isn't necessarily a programming question just yet but is a question that many programmers at corporations might be able to answer.
My company recently switched over to Office 365. We have a "noreply" email that sends out emails whenever our customers request work. The limit for Office 365 is 30 emails per minute or 10,000 emails a day. Currently the messages are being marked as spam and will not be delivered due to these restrictions. To over come this we have heard of services like mail chimp and mail gun but by visiting their websites I wasn't able to immediately infer on how to do this.
Can anyone provide some details on how they would overcome this situation? Also is your solution one that can be applied directly to Office 365 and the email or is it something that would require code change on the server sending emails (Using SMTP to send them).
It is not possible to change this restriction in Office 365. To quote Microsoft:
"Exchange Online customers who need to send legitimate bulk commercial
email (for example, customer newsletters) should use third-party
providers that specialize in these services."
What you can do is use a provider like Sendgrid or any other 3'rd party SMTP relay provider.
The provider will give you an SMTP hostname that you can point your code towards as sending server. What method of authentication to use will depend on the provider.
It is important to remember that if your domain uses SPF (which is highly recommended) that you include the new providers systems in your SPF record to ensure that it is not marked as spam.

What email server or online email service allows for creating unlimited email alias for an inbox (via API)

Here is the reason for my peculiar question:
I am working on a mortgage application for a mortgage broker where each mortgage application is a record. Now this broker will take each of the applications he has received and enter this application (in an up line lender's system) and during the life of this mortgage application, he receives notification emails about updates from the up line lender.
It is required that in this application, all emails pertaining to a particular mortgage application are visible under that record.
My plan is to have all emails collect in a single inbox, and give that inbox an alias corresponding to the record id of the mortgage record. The alias remains active as long as the mortgage application is active and the broker cares for receiving these updates. Once the mortgage application record is dead, that alias is removed.
When displaying the particular mortgage record, I can query the mail server for the emails where the to address is the alias of that particular record.
My key requirements are:
The email server or email service should allow for about 400-500 aliases at a time.
Should have an API interface for creating and deleting an alias.
As far as the creating/deleting API is concerned, Google Apps (https://developers.google.com/admin-sdk/directory/v1/guides/manage-user-aliases) really fits the requirement, but has a 30 alias limit.
Does Microsoft Outlook online mail support this kind of API and ability to create mailbox alias?
If we went in the direction of having a Microsoft Exchange Server 2010/2013, would it allow programmatic access to create aliases? What would be the license cost?
Thanks in advance for looking this up.
With update from #mti2935, I am considering a catch-all solution rather then deal with creating aliases.
So, now I think all I need is to be able to process the emails. What's the best means of processing emails (in my case, I will simply have to look at the "to" field and put the emails in different buckets).
I have found a third party service that can help me parse emails. Definitely going to try that out and provide an update here.
Service: https://postmarkapp.com/inbound
Referenced by a post on: How to setup a mail server?
One option to consider is to setup a mail server using qmail, configured as a catch-all for your domain, such that all mail to *#yourdomain.tld forwards to a script which parses each incoming message, scrapes the to, from, subject, etc. logs the messages in your database, etc. It's easier than it sounds to setup. See How to setup a mail server?. This can be done fairly inexpensively on a Rackspace or AWS cloud server.

SMTP server sending rate guidelines

I am build a tool that initiates an SMTP transaction with a domain to see if (a) that domain can receive emails and (b) the desired address exists on that domain. I will be batching large groups of email addresses (10,000+ at a time), but I don't want to bombard the server and get blacklisted. Are there guidelines for how often is it safe to communicate with an SMTP server?
I know about the VRFY command, but it is not implemented across the board. I plan to attempt to use the VRFY command and fall back to using,
MAIL From:<user#example.com>
RCPT To:<first.last#example.org>
QUIT
to see if the message will be deliverable. Again, are there guidelines on how often I can initiate an SMTP transaction like this on a domain?
Edit:
The purpose of this is to create a tool that my organization can use to (a) clean some bad emails from several largely inactive lists so that we do not have to pay our email delivery system to send potentially thousands of emails that will bounce, and (b) check an email when a user subscribes to a list so that we reject emails like aoghuifdgsiuvb#gmail.com.
First of all, spamming is bad. Always ask user wheter she wants to receive newsletters.
"Unsort" mail addresses by domain, leaving the "distance" between e-mail addresses with same domain as big possible.
I think it's not the programmer's decision. There should be a config value which tells a minimum amount of time between two mail sending to the same domain. You should set up a limit also for that config value, avoid setting it to zero or low value.
The only universal guideline I believe can be offered is "don't do this". If you behave like a spammer, you will be treated like a spammer. In the optimistic scenario, sites will already have controls in place, and silently throttle or block you. In less ideal scenarios, they will initiate actions against you on the (reasonable) assumption that you are collecting addresses for a spam list.
A better soluton would be to actually follow through the whole SMTP session, sending a user an email with a verification code/link. This has the advantage of showing that the user actually has control of the address in question and it keeps you from looking like a spam bot.
Volume is not as much the issue as reputation. Let the user know you're about to send them an email in your web flow. This means they're much less likely to mark it as spam.
some hosts have clear and defined guidelines as to how many emails can be sent per hour.
So i guess this would depned onyour hostng service provider, UNLESS your hosting your own mail server off course.

How are SaaS/Mult-Tenancy apps implementing email notifications (sending and receving)?

Given multi-tenant application, How are vendors implementing email notifications from an email account setup and programming perspective:
Sending emails could come from a generic account: eg notifications#VendorName.com or noreply#VendorName.com, this seems reasonable considering reply addresses and lilnks can be contained within the email contents.
Receiving Emails: How would an application receive email, for instance; to generate support tickets or assign comments in an email to a project/task. I have seen ID's within the subject and some reply to addresses containing the account name eg: notifications#AccountName.VendorName.com
I realise one can programatically connect to a pop3 server and receive emails and look for the IDs with the subject, but is there a way of setting up and receiving email to a single pop3 account from multiple sub-host name email addresses (not sure on terminology there) eg: noreply#AccountName1.VendorName.com or noreply#AccountName2.VendorName.com and check the Account Name from the address? (similar to checking subdomains on a URL)
Any practices, experience, comments or sughestions?
(not sure its relevant, but using C# asp.net-mvc and services etc)
For sending notification emails, we have a notification send to address associated with each account and simply send from our domain to that address. Our from address is monitored and replies end up in the CSR work queue.
For inbound emails, we use FogBugz (from the makers of Stack Overflow) for case tracking. That accepts new cases via email (e.g. cases#mycompany.com). Tickets are auto-created from the email. My only complaint there is that the customer needs to check an obscure link for case updates (no "my cases" web portal, but maybe that will come out in an upcoming version of FogBugz).
We have a custom field in FogBugz to indicate the customer the ticket is from. We could theoretically write a plugin to FogBugz that auto-assigns that using the senders domain, but I guess the CSR's haven't complained loudly enough yet :-)
We (at muHive) are an inbound email/social conversations management product. If you are looking at a handling inbound email or social media conversations from customers, we have an impressive toolset.
For our own outbound needs, the simplest way is to use an Email sending API. Don't bother with SMTP sending by yourself. We use Amazon SES and have also tried Sendgrid which gave us additional benefits like delivery status and email parsing.
There are two ways in which you can handle multiple accounts to a catch all email address. If your target system can differentiate between different customers and assign tasks to the correct representatives based on either the content/sender, ask all your customers to send an email to support#company.com.
As you rightly said, you could also create *accountName_support#company.com* email addresses and use different accounts on whatever CRM/Support solution use to manage these emails.
Another approach is to have your customers send you an email to support#company.com and you use a rule based system (like muHive) to forward these mails to the appropriate account executives based on the customer/account who sent the mail.

Sending Email Broadcasts

I'm working on an application that will allow management to send registered users (opt-in) broadcast emails at regular intervals, or based on various other criteria. In any case, I'm curious as to whether I should send a separate email to each recipient or bcc all of them on a single message. Currently the email list would be about 1500 recipients, but it should scale all the way up to at least 25k without problems.
Thoughts? Am I getting into a range that I need to worry about being put on spam lists?
Yes, I've had spam list problem with mailing lists of that size, managing email lists for non-profits.
One wants to take extra precautions: make sure your email has SPF records, write a script to send the emails in batches, paced out over time. Definitely send them one one at a time, not as bcc, as direct mail has a better chance of arriving. Make it very easy to unsubscribe. Include people's subscribed email in the message sent -- often people have email forwarded to another account and then try to unsubscribe that account and get frustrated.
Even so, don't be surprised if you have to change your IP at some point.
You are getting into that range. This is the point where I would look to get a third party to send the email on my behalf. Let them worry about being marked as spammers, supply the bandwidth, etc.
I recently built an application with those same criteria. We do the emailing in-house, and send one email to each recipient.
Do use domain keys signing or be sure to use SPF records for your domain. We didn't do that at first, and were blacklisted by a number of different ISPs. Fortunately, it is fairly easy to get them to unblock you. Most will include an online form you can fill out or an email address you can use in the server bounce message.
Don't try to implement the actual email sending yourself. That's a huge waste of time. Either outsource the entire process to one of the many reputable vendors out there (Many organizations I deal with use Constant Contact, and it works well), or run a garden-variety mailing list server (e.g. Mailman) in-house.
Either way, take efforts to make it very easy to unsubscribe (good vendors have that covered), to authenticate that messages are from your company, and to show that your company is not spamming. Real mailing list server software supports all of these goals, by adding proper headers that identify the source very clearly and making unsubscription easy. For instance, Gmail will now offer to send unsubscribe requests in response to mailing list messages marked as 'spam', as has AOL for a long time.
Definitely set up SPF and DKIM if you can manage it.
Finally, whatever you do, make sure you keep logs of your subscriptions, so that if someone does accuse you of spamming, you can defend yourself.
The task is mostly uninteresting on a strictly technical level. You should worry about what happens when a recipient thinks that your list's content is spam and starts (a) complaining or (b) flagging the message as spam with one or more anti-spam service providers. Something like this is bound to happen with a list of the size you describe.
If you are prepared and have the time handle such cases, go for it, at least for a start. (Changing your mail server's IP address as Devin Ceartas suggests won't be of much use by the way.)
If you want to build your own thing, I have two pieces of advice:
Unsubscribing has to be easy, no more than one or two clicks. Using Mailman or any other mailing list manager that was intended for discussion mailing lists is asking for trouble.
BCCing the same message to 1500 (or 25k) recipients may take some load off your mail server, but it has one serious disadvantage: You won't be able to use VERP in order to determine if all addresses that have once been subscribed to your list are still valid. (Large mail providers tend to classify messages as spam if there are delivery attempts to many invalid addresses.)