Was hoping for some ideas as to a service to which I can set up an inbound-only email system. In other words, I will have multiple users on the system, each can receive their own email... but at the moment... at this time, I am not focused on the ability to send or reply to messages, only receive them and send to the appropriate user. I looked into Postmark... They seem to have some great functionality.
CloudMailin Is another alternative. However there are effectively three options for setting up something like this.
Use an existing, traditional, email server and poll for the emails
Setup your own email server and create a script to run when you receive an email
Use a third party solution, as you've already mentioned.
I went through for of these for Rails a little while back here, but all the information is still relevant.
Related
As the title says, I would like to know if there is any way to send emails without having to use an external service, that charges me for sending the messages, or having to use an SMTP server in which each user has to be registered.
I have also seen pages like email.js but I don't want to have to pay for that if there is a possibility to do it on my own. It is also not useful for me to open the Gmail or messaging application of the device itself since I already know how to do that and it is not what I want.
For better understanding, I will give an example of what I want to do.
What I want is that from my application the user writes a message and from there that email message is sent to several different users from a list, without having to log in or anything, since the emails will be sent from my own email account. gmail that I have specifically created for the application.
I have seen the smtp server but from the information that I have seen that server implies that I have to log in to be able to have the token and that is not what I want because I want that once I configure everything there is no need to do anything else that people receive your messages and that's it.
I don't know if this is possible but I hope someone can help me.
Sending emails without your user logging in would require you to have either the credentials stored in the app (which is unsafe) or use a custom backend server that will host all the credentials that cannot be extracted. I would advise going with the backend route because it is easier to setup and your application will simply perform a HTTP request to get it done.
From the documentation of the mailer package, you can implement the server method pretty easily and get it moving. You will have to find a free web hosting service to deploy to.
There would really be otherwise no other way to get what you desire for virtually free.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
In Cuba, web access is extremely censored, so I created a tool that allows more than 50,000 people to browse the Internet through email. Cubans send me an email with an URL in the subject line, and I email them back with the response. Read more at https://apretaste.com.
It was working like a charm, till the communist government of Cuba started blocking my emails. My solution was rotation.
I started with Amazon SES, and I was changing the domain each time it was blocked, but Amazon adds a header to all emails, and once they blocked the header no email from SES was able to reach Cuba any more. The same happened with Mailgun and others, they all add headers.
Currently I am creating Gmail accounts and sending via SMTP, but Google blocks me for no reason and only allows to send 100 emails a day per account. Also I can only create few emails using the same IP address/phone, so I was forced to use anonymous proxies and fake Chinese phones. Now I am fighting a war on two fronts.
An email can be blocked by three parameters: IP address, domain, and email address.
It will be terrific if I can set up my own Postfix server at a VPS that auto-rotates the IP address. Even better if I can simulate "gmail.com", to avoid purchasing a new domain every day.
All the intents to create what I call "the ultimate sender" just either reach the spam folder or add unwanted headers making it too easy to block. I feel exhausted. I hit a knowledge barrier here.
I know I am crossing to the dark side, but this is for a very good cause. Thousands count on this service as their only source of unbiased news, social network and to feel part of the 21st century.
Can you please help me implementing "the ultimate sender", or pointing to another solution that I may be missing?
I have a few suggestions for you.
The first one relies on The Onion Router also known as Tor.
Since you are crossing to the dark side, why not also take a look into the darknet?
Take a look at this list of Tor email providers. If you have your own email server that can be accessed through Tor, it becomes much harder for anybody to stop people from using this service. After all, Tor was developed to offer people uncensored access to the web.
You can read about Tor in detail here, it uses Onion Routing and this is how you would set up your server to use Tor.
Here is an example how you could use it:
The steps that involve the setup, receiving an URL request and sending back the reply are as follows:
Set up an email server.
Configure your email server to use Tor.
Publish the public service name. (e.g. "duskgytldkxiuqc6.onion")
Deploy a client that takes the service name and a URL, and let it send an email with a request to your server.
The client now waits for a reply.
You send a reply and the client receives it.
You can change your service name on a regular basis, but you need to make it accessible to those who will use this service.
Having an own email server means being able to control the email header.
Here is one example how you could make use of it:
Configure your email server so that it receives and recognizes
emails which contain the requested URLs.
Before you send a reply modify the email header so that it shows a random IP address and a random sender email address including a random domain name.
Send your reply.
Sending an email that way means that you cannot be replied back to. But since your reply already contains the requested information there is no need to.
I hope this helps.
Crowd source it.
Find a way that volunteers can send some emails for you. This is the only long term approach that I can think of. A simple web interface with mail to links would be be enough to get started although there are other potential problems with this approach too.
Because you are talking about low numbers of users, you could also use crowdsourcing to create the single email address per person approach. They can create an account on a specific set of email providers and give you the credentials. This would allow the single email per user approach or could be used to rotate through a large set of email accounts to send emails.
The simplest solution is perhaps to set up a local SMTP server on your own computer. You don't even need a server per se.
https://sourceforge.net/projects/winsmtpserver/
There are many other such applications. They are usually used to test SMTP functions during local development, but there is nothing against actually sending spam through them.
I know this would be quite a large task, but how about pairing the users with one or just a few emails so they always receive an email from that email.
I'd assume people wouldn't have more than 100 queries per day, if so they could start receiving them from a backup email
I'd imagine it would look less suspicious for them to appear to be in constant contact with one unique email rather than 50,000 being in contact with one
I know this would be a huge undertaking, but I feel like it solves your issue.
Since the users are willing to receive emails form you then your shouldn't be blocked.
When you mentioned you are getting block does it mean your mail is going in spam or is getting lost in between sending and receiving or it is getting bounced back??
My suggestion would be to setup your own mail server and follow as below:
-Get approx 25 or more ip to rotate. (IP is the most imp part which is tracked and is accountable for the reputation of your mail server)
Don't start sending emails in bulk from the word go it is better to gradullay increase the email volume so that mail server reputation nicely built
keep changing the format of the email often
encourage user to add yourself to there contact list
your best part is user are willing to receive emails from you and you would reply to revived email is the USP of yours but still i will recommend you to register for FBL so that you would know which user is reporting you as spam and you can remove him from your list and never send him email again.
using best practice to send emails like dkim, SPF, dmarc are also vital.
Hope my answer was of some help to you. If you need step by step guide to step up mail server let me know.
My friend, do you remember what made Hillary Clinton lose the last elections to Trump?
It was the "mail" affair. And what was it? People discovered she shared confidential information through a non-official, non-governmental email account (i.e., she used some Gmail, Yahoo or another of a kind). Until here, nothing new with direct relation to your matters. But there is an small particularity on this history, and this can put, maybe not a solution, but maybe a light on a new path you could follow: Clinton actually never sent those emails; the email account she used had the password shared and the communication between people (Clinton-someone) occurred only using the drafts of the account.
How? One side logs in and accesses the drafts folder. There he/she reads the last message and edits it, cutting and writing new data - then save the draft message. On the next turn, the other side of the communication line logs in and do the same. And so forth, so never really sending those messages, but instead just updating the drafts (this "Hillary" method does schooled people... Dilma Rousseff, impeached ex-president of Brazil, actually did this method down there in Brazil too).
So, maybe if you could establish a pact with your user that he/she doesn't delete the account's password, you could pass those information by this method - without "really" exchanging emails. Maybe a "parent" email account (some that could reset a lost password) could be useful too.
Alternative: aren't you able to contract a regular HTTP webserver? You could rely on FTP to publish data to your user, he/she asks for it and you publish a page with that content.
Salvi, have you tried something with Telnet? OK, we are talking here about a text-only environment, but if nothing more would rest in the future, this could be better than nothing. Maybe you could implement a podcast-like, or push-like service based on it. Look what people do with it with references to your walk on the dark side...
If in Windows, open your command prompt.
Type telnet and press Enter.
Type "o" without quotes and press Enter.
Type "towel.blinkenlights.nl" without the quotes and press Enter.
For an application we are building, it is required to give certain registered accounts the ability to send emails to other registered accounts.
As part of the registration, we obviously collect the real email address of every user.
I do not want to expose any of my users' email addresses so I would like to have the ability to proxy them through fake email address that basically forward to the real email address.
For example, if someone want's to email John Doe, they would send an email to abcdefg12345#mysite.com which would then forward the email to john#johndoe.com.
In case its not obvious, the purpose of this is to protect the end user from spam and keeps their real email address private. Since my application acts as the proxy, I could easily block certain email's from going through.
The most famous example of this is Facebook's email proxy for Facebook Apps.
My Question: Are there any patterns, servers, 3rd party services, or libraries that provide such a feature? Does anyone have any suggestions for how this could be built?
I've never seen a service that offers this directly. The hardest part here is the receiving of the emails and wiring things up to your app for the authentication. You could use a service like http://cloudmailin.com in order to receive the email and then forward it on or even use some sort of custom install. Another option would be to create a script that modifies a server such as postfix's configuration.
Finally although I wouldn't recommend it you could try and create your own mail server to do this. I would read up a little more on SMTP/IMAP and see what options you have.
It looks like there is no 3rd party service or tool\library to accomplish this. It is going to be a bigger task than I was hoping for so I will be putting it off until I have the time to implement it.
I think the solution is to use a mail daemon that has an API or at least allows you to manipulate the users\emails\aliases in it such that you can create new mailboxes on demand and set them to forward from someuser#proxy.mysite.com to user#theirdomain.com
I found out that there are services that provide this type of functionality as part of their offerings:
http://mailgun.net/
http://www.sendgrid.com
Both of these services are very cool and offer quite a bit for sending and analyzing emails including the ability to create forwarding\proxy emails.
I have an application that sends emails when a user creates/modifies a record. I would like my users to be able to reply to the email that was sent to them and have the web application receive the email, parse it and update the record automatically. I have seen this done in web apps like Basecamp. The email usually says "Reply above this line", and if you simply reply to the email, you don't have to log in to the web application in order to update your ticket/conversation.
How can I go about implementing this sort of functionaly? (I'm not looking for a particular language implementation, but rather a language agnostic solution).
There are 2 ways you can do this:
You could use a Procmail filter to pipe the incoming email to your script. This would need some 'nix knowhow to setup - but it's certainly possible to do what you described via this method.
Use a service like MailGun - they do all the hard work of setting up and configuring the mail server stuff and expose it to you via a nice programmable web API. I've been evaluating it this week to solve a similar problem like the one you are having and I can tell you: it is really cool and I highly recommend you check it out yourself.
You'll need to implement a service/daemon that polls an email inbox for new messages. To relate an incoming email to the corresponding data, you can include an id in the outgoing email's subject.
I agree you should created a system to receive the incoming email but I don't necessarily agree that polling for it is the correct solution. Take a look at a blog post I wrote on the subject here. It relates to Rails but the concepts should work in any language. That's why we wrote the CloudMailin system to provide a better way of receiving the email.
Also you can use a unique from address for each email that would prevent the user from altering the subject line being a problem. The disposable part of an email address is useful for that. reply+user123#example.com for example.
A number of applications have the handy feature of allowing users to respond to notification emails from the application. The responses are slurped back into the application.
For example, if you were building a customer support system the email would likely contain some token to link the response back to the correct service ticket.
What are some guidelines, hints and tips for implementing this type of system? What are some potential pitfalls to be aware of? Hopefully those who have implemented systems like this can share their wisdom.
Some guidelines and considerations:
The address question: The best thing to do is to use the "+" extension part of an email (myaddr**+custom**#gmail.com) address. This makes it easier to route, but most of all, easier to keep track of the address routing to your system. Other techniques might use a token in the subject
Spam: Do spam processing outside the app, and have the app filter based on a header.
Queuing failed messages: Don't, for the most part. The standard email behavior is to try for up to 3 days to deliver a message. For an application email server, all this does is create giant spool files of mail you'll most likely never process. Only queue messages if the failure reasons are out of your control (e.g., server is down).
Invalid message handling: There are a multiple of ways a message can be invalid. Some are limitations of the library (it can't parse the address, even though its an RFC valid one). Others are because of broken clients (e.g., omitting quotes around certain headers). Other's might be too large, or use an unknown encoding, be missing critical headers, have multiple values where there should only be one, violate some semantic specific to your application, etc, etc, etc. Basically, where ever the Java mail API could throw an exception is an error handling case you must determine how to appropriately handle.
Error responses: Not every error deserves a response. Some are generated because of spam, and you should avoid sending messages back to those addresses. Others are from automated systems (yourself, a vacation responder, another application mail system, etc), and if you reply, it'll send you another message, repeating the cycle.
Client-specific hacks: like above, each client has little differences that'll complicate your code. Keep this in mind anytime you traverse the structure of a message.
Senders, replies, and loops: Depending on your situation, you might receive mail from some of the following sources:
Real people, maybe from external sources
Mailing lists
Yourself, or one of your own recipient addresses
Other mail servers (bounces, failures, etc)
Entity in another system (my-ldap-group#company.com, system-monitor#localhost)
An automated system
An alias to one of the above
An alias to an alias
Now, your first instinct is probably "Only accept mail from correct sources!", but that'll cause you lots of headaches down the line because people will send the damnedest things to an application mail server. I find its better to accept everything and explicitly deny the exceptions.
Debugging: Save a copy of the headers of any message you receive. This will help out tremendously anytime you have a problem.
--Edit--
I bought the book, Building Scalable Web Sites, mentioned by rossfabricant. It -does- have a good email section. A couple of important points it has are about handling email from wireless carriers and authentication of emails.
You can set the address that the email is sent from, what will be put into the To: address if someone just presses 'Reply-to'. Make that unique, and you'll be able to tell where it came from, and to where it must be directed back to.
When it comes to putting a name beside it though '"something here" ' - put something inviting to have them just reply to the mail. I've seen one major web-app, with Email capturing that has 'do not reply', which turns people off from actually sending anything to it though.
Building Scalable Web sites has a nice section on handling email. It's written by a Flickr developer.
(source: lsl.com.au)
EDIT: I misunderstood your question.
You could configure your email server to catch-all, and generate a unique reply-to address. E.g. CST-2343434#example.com.
A polling process on the server could read the inbox and parse out the relevant part from the received email, CS-2343434 could mean Customer Support ticket ID no. 2343434.
I implemented something like this using JavaMail API.
Just a thought.
The best way to achieve this will be to write a window service that acts like a mail client [pop3 or imap]. This windows service should execute a timed action triggered by a timer, which connects to the mail server and polls the server for any unread message(s) available in the email inbox. The email ID to check for is the email ID on which the users will give their input on/to. If the windows service client finds that there exists any new mail(s) then it should download and filter the email body and push further for processing based on the user input in the email. You can host the input processing in the same windows service but it is not advisable to do so. The windows service can put the inputs in a special application directory or database from where your main appication can read the user inputs received in email and process them as needed.
You will be required to develop a high performance TCP/IP client for doing so. I advise you not to use the default .Net library due to performance issues, instead use one of the best availabel open source TCP/IP implementations for .Net like XF.Server from kodart. we have used this in our applications and achieved remarkably grear results.
Hope this helps..
Bose has a pretty great system where they embed a Queue and Ticket ID into the email itself.
My company has the traditional Case # on the subject line, but when CREATING a case, require a specific character string "New Case" "Tech Support Issue" on the subject line to get through the spam filters.
If the email doesn't match the create or update semantics, the autoresponder sends an email back to the recipient demonstrating how to properly send an email, or directs them to our forums or web support site.
It helps eliminate the spam issue, and yet is still accessible to a wide technical audience that is still heavily email dependent.
Spam is going to be a bit of a concern. However since you are initiating the conversation you can use the presence of your unique identifier (I prefer to use the subject line - "Trouble ticket: Unable to log into web...[artf123456]") to filter out spam. Be sure to check the filter on occasion since some folks mangle the subject when replying.
Email is a cesspool of bad standards and broken clients. You need to be prepared to accept almost anything as input. You will need to be very forgiving about what kinds of input are tolerated. Anything easy for you to program will likely be difficult for your users to use correctly. Consider the old mailing list programs that require you to issue commands in the subject line. Only hardcore nerds can use those effectively. And some of those trouble-ticket CRM things you mentioned have bizarre requirements, such as forcing the user to reply between two specific text markers in the text. That sort of thing is confusing to people.
You'll need to deal with email clients that send you formatted text instead of plain text. Some email clients still don't handle HTML properly (cough GMail) so your replies will also need to be designed appropriately. There are various ways in which photos might be "uploaded" via email as well, especially when mobile phones are involved. You will need to implement various hacks and heuristics to deal with these situations.
It's also entirely possible that you will get email that is valid but unusable by the email parsing library you are using. Whether or not this is important enough to roll your own will be a judgement call.
Finally, others have mentioned using specific email addresses to uniquely identify a "conversation". This is probably the easiest way to do this, as the content of the mail will often not survive a round trip to a client. Be prepared, however, to get mail to old IDs from old customers who, instead of opening a new ticket somehow, reply to an old ticket. Your application will probably need some way to push emails with an old ID into a new case, either manually or automatically. For a CRM system it's very likely that a user would reply to an old email even if you already sent him a new email with a new ID in it. As for whether you should use some.email.address+some.id#yourdomain.com or just some.id#yourdomain.com, I'd go with the latter because the plus-sign confuses some email clients. Make your IDs guids or something and have some way to validate them (such as a CRC or something) and you'll get less junk. Humans should never have to type in the GUIDs, just reply to them. The downside is spam filtering: a user's computer might view such email addresses as spam, and there wouldn't be an easy way to whitelist the addresses.
Which reminds me: sending email these days is full of pitfalls. There are many anti-spam technologies which make it extremely hard for you to send email to your customers. You will need to research all of these and you need to be careful, and do some testing, to ensure that you can reach the major email providers. A website like Campaign Monitor
can help you if you are sending email.