locked
Implementing email functionality on web site RRS feed

  • Question

  • We need to add email functionality to our secured website (asp.net).  The purpose of this is to allow our logged in customers to send a message to our customer service department.  Customer service department will respond to the message.  The website will have inbox, sent items, reply, and attach files functions.  The messages must only be available to customer via the website, due to possible confidential content within the email body.  That is, we cannot use the customer's public email address to respond to these messages.

    I am thinking of using Exchange to implement the backend message repository and developing code to send and get the messages.  This implies to me that a mailbox/account needs to be created for every registered customer (are there alternatives to this?).  Am I out of line with thinking of using Exchange.  Are there alternatives to Exchange?

    Tuesday, August 31, 2010 2:53 AM

All replies

  • Hello there,

    Some links are given below which are very useful to you.

    Sending Web eMail in ASP.NET
    http://articles.sitepoint.com/article/sending-web-email-asp-net


    HOW TO: Send email using System.Net.Mail
    http://forums.asp.net/t/971802.aspx



    Using ASP.NET To Send Emai
    http://www.developer.com/net/asp/article.php/3096831/Using-ASPNET-To-Send-Email.htm

    Sending Email in ASP.NET 2.0
    http://www.4guysfromrolla.com/articles/072606-1.aspx

     

    Hope this helps.

     

    Regards

    Phijo MP


    PHIJO MP
    Tuesday, August 31, 2010 3:06 AM
  • Hi GMSSMG! I am writing to tell you about an option. The idea is to create your own compose, read and reply message pages. Here you go the scenario: 1 - the customer access a 'compose page' to write the message. 2 - On click send, the message is stored in your database, and a notification is sent (by mail like Pijo MP said) for custumer service depto. 3 - the custumer service read the message. To reply, they click in a link in the message foot. 4 - the link opens a 'reply page', from your aplication. 5 - the customer service depto write the reply message 6 - On click Confirm, the reply message is stored in your database 7 - Next time the customer log in, he/she can access a 'read page', with original messages and replies related to this user. Well, as I told you, it´s just an more option. Maybe Exchange APIs would provide more funcionalities. Have a nice day.
    Wednesday, September 1, 2010 5:09 PM
  • Version, thanks for your reply.  Sounds like a viable option.  What could we do about file attachments in either the send or reply messages.
    Wednesday, September 1, 2010 5:56 PM
  • See

    http://www.stardeveloper.com/articles/display.html?article=2002022802&page=1

    http://www.codeproject.com/KB/aspnet/SivaEMailSample.aspx

    Wednesday, September 1, 2010 6:02 PM
  • Hi GMSSMG,

    I think the subject here is more about how to upload and download files from web pages.

    I mean, you can upload the files (on the compose and reply pages) and provide link to download then (on read page).

    You can find some useful links about this, like

    http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=115

    Ps: If you are expecting a high number of users/messages/attachments for your system, maybe the use of Exchange would be more suitable to manage these messages and attachments in the future. So, it will depends on the size and resources you can expend in this project.

    Hope this help.

    Best regards.

    Wednesday, September 1, 2010 8:50 PM
  • It's often a nuisance setting up email functionality on websites unless you have easy control over configuring them.

    Clients I've worked at often have some distant department who looks after the servers and is very reluctant to nke the changes necessary to enable mail from a server.  It's proved impossible in some instances.

    With attachments.  Although you can store files as blobs in a database it's often more practical to save them separately on a file system and store a uri to them in the database.  Depends on how big your files and what your traffic is.

    Another option is some sort of secure ftp.  Give each customer an area they load stuff to.  Use a filewatcher to inform support when someone raises an issue.  This is obviously more your quick and dirty approach but handles big files better IMO.

    Then there's a combination of both.  Your web site allows the user to upload via secure ftp, maybe with some encryption.  Also adds an entry to the issues table or sends an email.  That way your web site still runs smoothly whilst a huge file thumps onto your (separate) ftp server. 

    Thursday, September 2, 2010 8:27 PM