I'm developing a site where I need to send HTML newsletters to a mailing-list.
I have build a html frame where I have my "View in browser" and "Unsubscrib" links (which of cause will vary). In the admin module, I post html and uploads images for the html-newsletter. Is this a good way to do it?
How should I send the e-mails the XX.XXX persons? I can't use BCC because the unsubscribe link will vary. So I guess I have to sendt all the e-mails seperately. But the code shall be fault tollerant so only half get the newsletter if there is a error.
Best regards,
Lasse
Hope these are helpfull:
Use MailDefinition as a templating engine http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.maildefinition.aspx If your numbers are large you may look into not using SMTP as a transport protocol, but rather generating files for each email you wish to send and then putting them directly into the "Drop" folder of your SMTP server. Mirosoft SMTP Server allows this quite easily.
Use a unique bounce back email address for each email (but include a reply-to to a real address, such as office (at) yourdomain.com. Let those bounce back email addresses point to one common account and after sending your newsletter remove all addresses that bounced from your database.
As for fault tolerance, I don't think I quite understand. Why would you only want half to ge the newsletter? I would catch any server related issues and stop the processing immediately, and any client related issues (client's email does not work, see 2.) are either skipped and logged (if detected during processing) or processed later (if detected later).
Depending on your local laws check opt-in/opt-out policies.
Also take a look at embedding images directly into the html (a not well known fact is that you can embed images directly into ) this will usually make email size larger but it will let Outlook display those images directly without going to your server. Of course if you want newsletter tracking via an image beacon or similar then server images are what you want.
Of course check all common email clients for correct display. AFAIK it is almost impossible to send a format that each and every client will display correctly unless you send plain text :)
yes you will need to send the emails one by one if you want a unique unsubscribe link for each client. you may send the same email to everyone if you put a textbox on the page where people can unsubscribe by typing in their emails.
as for the email being sent out, you have the right idea. you need to host the images on your server and call these from you html.
the html must be basic html 3.0 or something of the sort. this will ensure that most email clients will properly render your email.
be extra careful when making a mailing list, it can be very easy to get banned from certain servers such as google or hotmail.
Related
I am looking for a solution to stop multiple sign ups on an upcoming websites of mine, but I am looking for different alternatives besides IP saving and tracing that.
So I was thinking about computer ID saving on the server. Is that possible?
No, that's not possible simply because this information is never sent on the network. The only information you could reliably get from a user visiting your website is his IP address in addition to the standard HTTP headers which might or not contain information about the UserAgent he is using, the language he configured in his browser, ...
I have a client who has a crimestoppers' website. They want to provide visitors a means to submit anonymous crime tips, which would then be forwarded to a pre-established email address at the local police department.
What is the best / easiest way to accomplish this? The sender's IP address needs to be hidden. My client also needs to be able to pull reports showing how many tips were submitted and forwarded.
Many thanks!
A simple contact form can be used. It's up to the developer's trust to hide the IP. The submitter won't see anything what is being done using PHP.
You can then update a database with the tips being posted before sending the mails.
In terms of development, you can use a plugin such as Contact Form 7 and then use its hooks to save the tips submitted before sending the mails.
While it is rather simple to set up a contact form that submits to an email address (just use the excellent ContactForm7, as rrikesh's answer suggests). However, getting anonymity right (especially against a party that has as much power and resources) is tricky. You need to be clear about the level of anonymity that you can provide. Log files, document metadata or your ISP can easily give a lot of information away.
Here are two project that have different approaches. They're both not ready-made solutions to your question, but still relevant:
PrivacyBox:
This is a web service run by the German Privacy Foundation. It's basically a message relay like the one you want, except that the user has to trust the Foundation, not you. This model highly depends on the institution providing this service. I'm sure there are other, US-based services like this.
Briefkasten:
An open source software tool used by the German newspaper Die ZEIT.
a reasonably secure web application for submitting content anonymously. It allows to upload attachments which are then sanitized of a number of meta-data which could compromise the submitters identity. Next, the sanitized files are encrypted via GPG and sent via email to a pre-configured list of recipients. The original (potentially 'dirty') files are then deleted from the file system of the server. Thus, neither should admins with access to the server be able to access any submissions, nor should any of the recipients have access to the unsanitized raw material.
This is an attempt to automate the crucial steps to strip any identifying data from the submission and encrypt it, so only the intended recipients can access it.
You would have to host this yourself, though. And it's a Python app.
I have read a few other posts on here about mass emailing, but I need some other information. We want to integrate our mass e-mail system into our current application, but I fear this may not be a good idea. Does anyone have any input as to what kind of resources are needed to send, potentially, 1000's of emails an hour? We only have one web server right now and do not have access to our mail server. We do have full access to our web server, however. Would it be a bad idea to host the mass e-mail application on our current server? Should we have a separate sever to run this type of application and call the server via web services (WCF)? Each email would need to be sent separately because the links on the e-mail are for tracking and unsubscribing purposes. I appreciate your thoughts.
Daniel
Yes its a bad idea,
One of the key things for detecting spam, is the IP address it came from (Known as its reputation) if you start sending out alot of emails which end up getting marked as spam (Which is likly, even if the users said they wated to recieve email) your IP address could end up in trouble. I wouldnt fancy doing this on my webserver.
As for specs, your bandwidth is going to be hit hard when you start doing somthing like this. Although I think you would be suprised at how fast you can send out emails (Mail Server Dependant)
Either way when it comes to sending mass mail campaigns out, I'd speak to a third party if its somthing you are serious about, they have the knowledge and hardware to perform campaigns that are not going to damage your IP rep.
I think this issue all depends on your mail server. I've been in a project where we sent out 50-100K emails in a few hours and the main limitation was the capacity of the mail server. In my opinion it would be fine to have the mail client run on the web server as it won't be using too much resources if well written, the main question is what the mail server can take.
You can help your reputation on some email providers by contacting them and or filling out bulk mail registrations.
This is for yahoo:
http://help.yahoo.com/l/us/yahoo/mail/postmaster/bulkv2.html
I would not recommend using exchange for anything like this. You will want a separate bulk mail server like Ironport.
http://www.ironport.com/
Otherwise your internal emails will get stuck in the queue with all of your bulk emails which you definitely don't want.
The actual code involved does not have to be that complex. In my case we used an asynchronous task to loop over an email list table in the DB pulling out a batch of 20 or so at a time sending then sleeping for a number of seconds. Email providers do not like receiving hundreds/thousands of emails from a source at one time. Even better if you can stagger the list by providers.
Is there any mail queue concept in ASP.NET?
I want to send thousands of different mail to thousands of users (i.e. each user will have a different mail). I want to send the mail at a particular time, so each user receives it at a constant time.
There really is not mail queue in the Core framework. You can send individual messages synchronously or asynchronously, but you can't really send a bunch at once.
You can queue your messages by storing them to a database or file server and then kicking off a job to loop through your saved messages and send them off.
Also, not all of your users will receive the messages at the same time, even if you could send them at the same time. There are too many external variables and dependencies (network traffic, mail server loads, spam filters) to accurately predicate when or even if your users receive their messages.
There's no native MailQueue concept within .NET framework. The queue will have to be implemented yourself. In your case, you would like the mails for each recipients to be sent at about the same time for all batches. Am I right?
Well, this is a bit tricky. You can use any SMTP server, localhost or external ones. But that also mean although you can dispatch to the SMTP server at a specific time, there's no guarantee it will reach the recipients immediately.
There are a whole bunch of stuff on mail delivery which are not exactly programming related (grey listing, spam filtering etc etc).
The alternative is to have full control on the sending and have your app directly sending the mails to the recipients' mail servers. Well that is workable and I suggest you use a commercial or a good open source component for that. Anyhow, there's still a whole bunch of issues you need to deal with, (e.g. some receiving mail server like Yahoo might block the sending a few times and let it through after a few retries).
I've posted a related question, take a look at the replies here.
I want to create an in-house RSS feed (I work for 3 Mobile, Australia) for consumption on an INQ1 mobile phone, or any other RSS reader for that matter. However, testing it out on the phone's built-in RSS reader, I realize that without the ability to password protect the feed, or otherwise restrict access to it, I stand little chance of being able to develop this idea further.
One thing I thought of was to periodically change the Uri for the feed, so managers who had left the company couldn't continue to subscribe and see sensitive information, but the idea of making users do that would make it a harder sell, and furthermore is terribly inelegant.
Does anybody know how to make it so that prior to downloading a feed, a reader would have to authenticate the user? Is it part of the metadata within the feed, or something you would set in the reader software?
Update: I should have explained that I already have placed folder-level permissions on the parent folder, which brings up the normal authentication dialog when the feed is viewed in a browser, but which just results in a failed update with no explanation or warning in the phone's RSS reader, and is indistiguishable from the file being missing, when I next try and refresh the feed.
If the reader in the phone doesn't support HTTP Basic or Digest, your best bet is to create a unique url to the feed for each consumer. Have the customer login and generate a link with some token in it that is unique for that user. If the user ever leaves, you can then deny that token, shutting down access.
If you go this route, you probably want to investigate including the Feed Access Control bits in your feed. It's not perfect, but it is respected by the bigger aggregators, so if one of your clients decides to subscribe to the feed with Reader or Bloglines, things shouldn't show up in search results.
I believe you would set the permissions on the feed itself, forcing authentication, much like the Twitter feeds. The problem with this is that many readers (including Google Reader) don't yet support authenticated feeds.
The idea is to have authentication over a secure channel. These posts explain it pretty well:
RSS Security
Private RSS Feeds
Authentication by the webserver is probably the best solution, however to get round the issues of reader not supporting it (Google has been mentioned and I have issues with Safari) you could implement a simple value-key to append to the URL.
I.E.
http://www.mydomain/rss.php?key=value
Your system could then "authenticate" the key-value and output the RSS, invalid k-v could get a standard "invalid authenticate" message as single item RSS or return a 40x error.
It not very secure as you could see the k-v in the URL but it's a a trade off. An un-authenticated HTTPS would be slightly more secure.
Assuming your RSS feed is over HTTP then basic HTTP authentication would probably do the trick. This would either be done at the web server level (in IIS for example) or via whatever framework you're using to produce the feed (in ASP.NET for example).
The authentication scheme (basic username/password, NTLM, Kerberos etc) is up to you. If you're using WCF to produce the feed then these decisions are things you can make later and apply via config if needed.
Are you simply looking to authenticate consumers of the feed, or also encrypt it to prevent the information from being read by a "man in the middle". If you require encryption then SSL is probably the easiest to implement.
You should avoid simply "hiding" the RSS feed by changing it's name.
update:
Your question (with it's update) sounds like you're actually having issues with the RSS client on the device. You need to determine whether the phones RSS client understands how to deal with basic/digest authentication etc.
Assuming it doesn't, is there anything in the HTTP request that could allow you to associate a device with a user? Is there an HTTP Header that gives you a unique device ID? If so, you might be able to then perform a lookup against this data to perform your own weak-authentication, but you should remember that this sort of authentication could be easily spoofed.
Does the device have a client certificate that could be used for mutual SSL? If so, then that would be ideal.