I'm a big fan of the email feature available in Backpack, where it creates a unique email address per backpack page, and any emails sent to that address will be posted to the page.
My question is about how best to go about creating new email addresses automatically, and listening for new emails sent to those addresses. I'd like to do this from a C# service (I'm not using ASP.Net)
Has anyone tried to achieve this or
something similar before?
Are there libraries (preferably
FLOSS) already available which do
this or would assist me?
Is it possible to do this using a cloud-based
email service (and if so, what service?) and a
library for communicating with that
service (OpenPop.Net or similar)?
If your email provider supports setting up wildcard email on your domain, then you can do this with a single email account.
For example, Google Apps for Domains allows setting *#example.com to be delivered to myaccount#example.com. When someone emails sales#example.com or contact#example.com it will all be delivered to myaccount#example.com.
Then it's a process of getting all the emails. You then look at the to header in the email, match that with the name stored in your application for that user, and then process however you wish.
Be aware that you will get spam and other incorrectly addressed emails when you use this method. You will have to deal with these yourself (eg by discarding incorrectly mail that isn't addressed to a valid account).
I haven't played around much with incoming mails, but from the top level here is what you should do.
Create email addresses for the users based on any logic and save it in the DB.
Setup a mail server with your domain name and set one email account as a "catch-all" mail account. Any mail sent to your domain would then be caught under that mail account, in case the email address is not found.
Create a windows service, that would read mails from that "Catch-All" account. There are several libraries available to read mails using POP3 or IMAP.
Read the incoming mails to check the email address it was sent to, compare it with the values stored in the DB and process accordingly.
Check this question. it might help you with reading incoming mails.
The objective isn't to create email addresses, that doesn't really happen. What you do is accept email addresses at your system, what you accept is up to you. You could set up a mail server to receive any email sent to your domain, you could then parse the email To field and extract the 'name' portion. If it matches something you are listening for then you action it accordingly.
I don't think you'll find a library for this specific activity as it's rather insular. There are plenty of ways of receiving emails directly or indirectly and processing them in C# but I won't cover that as mail handling in .Net is well documented.
Related
If we have a program that is used to send a mail to store information on a popular mailbox such as gmail, hotmail etc. is it possible without hardcoding the password to send a mail to itself as a logg(a text file basically)??
Since i don't have my own website or host or anything similar, i thought that using a free mailbox to save some sensor logg history to a mail adress would be easy enough.
so the main principle would be basically to send to myself a mail containing the logg and that works great. But is it possible to avoid hardcoding the password into the client? So if i want to send the log to the mail, could we possibly send it to my mail with an unknown source(it's fully okay if it would go to the trash). As it looks now, i have to enter the hardcoded credentials into the program and then send to myself, otherwise it wont get it :(
Yes. You can create your own stmp server and connect it to your own e-mail. If you want to stay anonymous per se, you can use a temp mail.
C# xample can be found here: https://www.c-sharpcorner.com/article/sending-email-with-C-Sharp-using-smtp-servers/
You can, however, use almost any programming language to make an stmp server.
I have several inquiry forms that I'd like to use a Gmail account to authenticate and send through. The forms send successfully, but the reply-to address is always the Gmail account, rather than the person's e-mail who filled out the form. This is a problem for the client in that they can't hit "Reply" without changing the reply-to address.
I've poked around the Gmail account and don't see anything that appears switch anything on and off to fix this. Any ideas?
My guess is that this is a restriction when using gmail as your SMTP server. You could use a different SMTP server to send the emails like MailDrill or MailGun.
OR
...and I'm not sure this will work. You can configure your gmail account to allow you to send emails with a different reply address/alias, but each address requires confirmation.
The steps to do this are located here
EDIT: I just re-read your message. Since you're using form data for the address I think your only option may be to use an alternate SMTP server.
Sorry I don't have a better answer.
I want to send an anonymous email to my own gmail/hotmail/yahoo/any other mail service address (Im not trying to spam or something like that).
Why? I have a .NET application and I want to add a "Send log to the developer" feature (attaching the log) using SmtpClient. The fact is I've read like 30+ pages, and found out, i.e. gmail's smtp client doesn't allow anonymous connections, and many other things.
The idea is to receive a mail message like this:
From: logs#myapp.com (non-existent email really)
To: myrealaddress#somedomain.com (this would be my real address which will recieve the logs attachments)
Subject: Issue report nºX (auto-generated)
Body: From a textbox
Attachments: logs attached
Is this possible? If so, how do I achieve it?
The short answer is that you can't reliably achieve this. You can get it to work in some cases, but not all.
Most email servers these days have spam filters and rules for checking on emails, and in most cases an empty 'From' address will result in special treatment. Sometimes that just means a slightly higher spam score from the receiving mail server, but in some cases an empty 'From' address will result in your email being silently dropped in the bit bucket. You have no control over this, and neither will your users. It's all down to how the receiving mail server is configured.
The simplest option is generally to allow the user to configure a from address and SMTP server. Some servers will require login to send messages, so you have to consider that. Many ISP mail servers (and most internal workplace mail servers) don't require login if the connection is coming from an address owned by the ISP (or workplace) and the email address is one that is registered as belonging there. Some ISPs - and this number is apparently growing - require SMTP login to send mail regardless.
Another option is to set up a source domain, configure the SPF record for the domain to allow email from any IP address, and use a standard 'From' address in that domain. The downside to this is that once someone discovers that you've opened up a domain that way they'll start using it to send spam and you'll get shut down.
There are many other options that have their own problems. One of the problems is that they generally cost money - some setup costs, most options also with ongoing costs - or open you up to liabilities of some sort.
Give your users the choice. Let them try various options and see what works for them: no 'From' address, user-defined 'From' address (same as 'To' address is a good first try), partial SMTP login, full SMTP login, etc. If they don't trust your code enough to put their passwords in, let them create a throw-away account on gmail or something to run the messages through.
I was working on an application which would send emails automatically at specific time intervals to a valid email. Searching through the internet I found that most of the codes use the existing email accounts such as gmail.com to send email by logging in as an SMTP client. But my problem is that I won't be knowing the smtp server name of the users email(since the user is not generally aware of these things though he will be knowing the login/passoword). For example,
someone#gmail.com should give smtp.gmail.com and port number (465)
someone#nextek.net should give mail.nextek.net and port number (?)
someone#screaming.Net smtp.tiscali.co.uk and port number (?)
I got the MX records using the domain name of the email address, but I realized that it actually gives the available incoming SMTP server names.
For example gmail.com would give gmail-smtp-in.l.google.com along with four other server name if I ping using nslookup in command prompt.
Also what is the advantage of sending email by using an existing SMTP supporting email than sending directly by looking up the email server name through dns? Or is it not possible?
Correct me if I am wrong, since I am not much familiar with the protocols.
If you're not familiar with the protocols, it doesn't make sense for you to try to implement the protocol.
Generally, an application like yours doesn't need to worry about the details of the SMTP protocol. You would use an existing SMTP client library for your platform (I'm sure there is one for .NET you can use), and connect to an MTA (your MTA, not the recipient's), give it the email to send, and you're done. The MTA will take care of all the SMTP protocol details of figuring out how to get the email to the recipient.
Sending email is very similar to dropping a letter in the post box on the corner, and letting the post office figure out how to deliver it. You don't need to know which vehicle to put it on, or where the recipient's local post office distribution centre is, or any of those details.
You may choose to set up your own MTA using something like Postfix, or you can send email through your own Gmail account (of course you'll need a Gmail account and password before Gmail will let you do that).
I am developing a site for which I would like to protect buyers by anonymizing their email addresses.Similar to craigslist's system, when a seller needs to contact a buyer they should be able to send an email to an anonymized address such as 1425415125#mysite.com which will then be routed to the user's email address.
My plan right now is to:
Set up a bucket (catch-all) inbox
Generate a random key for each buyer which will be the user specific ('1425415125' above) section of the email address
Monitor the bucket inbox and parse out this user specific section. Once I know the user, the email can be forwarded to the correct address
My questions are as follows:
Can you see any issues with the above solution
Are there any open source solutions to the existing problem
Are there any gotchas that one should be aware of when developing such a system?
Thanks in advance
JP
I did something related, though not quite the same. I setup a catch all inbox on my existing pop3 server (you probably have one already I'm guessing). I then used OpenPop.NET to read all new messages on a timer (say every 30 seconds). In my case I stopped at just processing the messagse but it's easy enough to generate a new message to the appropriate address and copy the body over, then send the new message out on your SMTP server.
One problem I see with your setup, and maybe it's just a misunderstanding on my part, is that while you are protecting the users original email address they will continue to be reachable at 1425415125#mysite.com basically forever. If I understand the way craigslist works, each posting has a different email address, and once the posting has been deleted/removed (or shortly after) the email address stops working. This makes it so that people can't just keep bugging you on that email address. The solution to this issue is easy, just make the email address coorespond to a post id or some other id rather then the users id in the database. The lookup will be just as quick but they will have a new email address each time.
You may wish to look at mail "piping" - the ability for someone to send an email to a mail server, which then gets thrown immediately to an executable, which then forwards your mail onto the recipient (by pulling the real email address from the database based on the incoming address from the piped message).
My personal recommendation would be to check out HMailServer, which has a COM API (the admin side is written in PHP, hence the requirement for legacy interop), is free and open-source, and is very well-documented. It doesn't have mail piping built-in, but is easily extensible given the API and support for scripts which run on server-side message events
HTH,
Benjamin
I think this solution will make sense and is in use in a lot of cases. The hardest part is actually receiving the messages. You can actually handle all of this within your web app if you need to. I wrote a blog post highlighting a couple of ways to receive email in your web app. It applies mainly to Rails but the concepts should be transferable.
The way you are lookimg to do it is the way I created a similar service. I would not recommend you writing your own smtp server. Use an existing mailserver and just use polling or some event based api.
The benefits of using a 3rd party mailserver is you can use existing backup and management tools on it.
Edit: I just noticed this has beed answered here with a better explanation. Pipe incoming email to a script on Windows IIS SMTP?
I do not see any problem with your setup, infact that is correct way to do because if your scheduled application fails, the emails will still be in the catch-all email box. Only once the email has been successfully delivered to somebody, the email should be deleted. You will be able to monitor and log the activity of your own application to monitor progress and failures.
I do not recommend Piping because, if for any reason piping goes successfully but your exe crashes, you will loose the email. Tracking will be difficult. Scheduling the jobs will not be possible.
If your application is independent of mail server, it is easy to manage it and replace your mail server whenever possible. It is easy to extend.
In this you will have to use some pop reader library, and schedule your application to run frequently.
In addition to email, you may consider a pull rather than push delivery mechanism, e.g: a message center web frontend or RSS feed. I say this because deliverability problems to various ISPs can be very difficult to troubleshoot and in my experience your users will never believe it's their ISP.