I develop applications using the ASP.NET framework for my academic organization. We also have an exchange server for internal accounts.
Since my organization is under the umbrella of a larger one, all our internal exchange accounts also have external parent accounts with the same names.
I'm facing an issue where automatic emails triggered using the system.net.mail classes are correctly routed to the required email addresses, but they go into exchange account's inbox.
While this is not a big problem for some users, there are a few who want the emails to go to the parent accounts so that they can view emails while working from home.
I was wondering if there is any way I can achieve this at the application layer - to instruct the SMTP server to send mails to the external accounts with the same names and ignore the local active directory accounts.
Thanks.
No, you can't. The SMTP protocol doesn't have any spec for this.
I believe you would have to setup and point to an alternate relay for this to happen.
Related
I work for a subscription fulfillment company, where we handle the subscriptions to various magazines (renewals, invoices primarily). So we email out to the subscribers when they purchase a magazine, that we are charging them for their monthly/annually renewal or they sent us a question about their subscription and we are answering them.
As of right now, we are creating email addresses on our domain for each of our clients (the publishers), but the publishers want us to send out the emails with their domain name as the from (not ours).
I know this can be done because we purchased email blasting software and it does it without a problem (the clients put in SPF records so that it won't be marked as SPAM). The problem is that when our .Net (specifically VB.Net) application goes to send out emails with a From from a different domain, I get back that the user we authenticated to our internal SMTP server with isn't authorized to send out on behalf of the From.
I got a partial idea from Send SMTP with From address of another domain that maybe I could ask the publishers to issue us credentials to their SMTP server and have the .Net code try using their server and credentials to send out the email, but I would prefer not to go that route.
On the same note, our people use Outlook 2010 to answer most of the customer service emails, so it would be good if the solution for the .Net could also work for Outlook. If it doesn't, it doesn't, but at least the .Net one is a step in the right direction.
Now, I am a .Net developer, not an SMTP administrator (but I'm the closest to it that we have). So any instructions need to be detailed, please assume that I am ignorant in this area, so if you say go run program such and such, please state where program such and such is.
We just open a new e-commerce website and recently noticed Gmail treat our e-mails as spam (notice the red question mark). Our website run behind CloudFlare so the email server IP address is different than the domain.
We also did not send a bulk email at least not yet. There are some explanations in Google FAQ but not sure what it means or how I need to implement it. Can you please explain how to set these DKIM (preferred) or SPF.
Our website uses nopcommerce (3.70) and developed with ASP.Net.
Disclaimer: I'm not a "pro" at these things (more later):
IMHO, this is probably the simplest explanation of DKIM
SPF: in my own words: providing a DNS TXT record that identifies "where" all your emails (smtp/mta servers) can come from. The more complete/formal spec is here
You can implement both
Opinionated:
SPF is easier to implement
identify all the origins of your email, set them in your SPF record, which is a TXT record in DNS
DKIM: is more complex - your mail/smtp server/s must implement it.
As a "web developer" one can see how this would be done in ASP.Net/C#/VB - e.g. sign some payload and using HttClient send some signature in an HTTP header in some outbound request.
But this is done on an SMTP server, so unless you have one that already implements it, it's something you'll have to do...
IMHO, for DKIM, unless your SMTP/MTA implements it, I'd go for services that provide it. There are 2 types:
Transactional email services:
Not for bulk email. These are the usual "order confirmation" emails, standard support/customer service, etc. emails. They will likely have APIs for you to implement (e.g. sending your MailMessage using thier servers and/or constructing something that equates to it and send that "object" to their API).
Bulk email services
these providers will already have implementations because one of their core value propositions is "deliverability" of your bulk/marketing emails. They should (of course do your due diligence) have both implementations inherently. Will also have their own APIs for bulk email context.
Hth
Im currently in the process of exposing our internal CRM system to the web so our employees can use it outside out network. The data is being surfaced to our web application via asp.net WebAPI.
We have SSL setup on the website. But am thinking how else I can make sure the WebAPI is secure from malicious use. My ideas are:
Tracking what IP addresses are accessing the WebAPI and only allow addresses that we have validated are from employees. Problem with this having dynamic IP addresses we might be constantly updating a data store of valid IP addresses.
The user has to login to the system. So every request to the webapi will send across their login details which will be validated before the webapi will process any request.
Pass the device ID of the device using the webAPI and validate (pretty much the same as IP Address tracking in idea 1)
Having a unique clientside generated access token which much match up at the server side.
Has anybody got any advice on my security ideas I outlined? Is it to little or is it overkill?
Just want to make sure the data cannot be hacked, because my butt would be on the line if it did.
Thanks in advance
I would actually choose a totally different solution - updating valid dynamic IP's will be hell.
I would:
Create a new Project using the "Intranet Application" instead of using "Internet Application"
Host the application on your local office network
Set up VPN to your Office for your colleagues
Would this solution be possible for you?
I am using asp.net 3.5 with C#.
I want to integrate gmail into my site, just like any widget so that, people can login there and can access their gmail account. Actually gmail is blocked in my organisation & I want to access it via proxy that I can integrate in my website.
Thanks a billion.
Johnvey Hwang's Gmail API is probably a good place to start.
If you can't access gmail in your organisation, embedding it in another page is unlikely to avoid this.
Depending on how it is blocked, you may not be able to code any solution to access it.
If you can access your account via POP or IMAP then better than coding anything you could simply to use an alternative mail client (like thunderbird). This might work out of the box, or you could specify the server by IP address (209.85.227.19 should work). That should defeat many naïve web filtering implementations. If you can't access anything outside of port 80 then you could set up your own webmail solution such as SquirrelMail on your own server and use that to access your Gmail IMAP.
Of course the best solution would be to access your personal mail using your own internet connection rather than your work one. Gmail has excellent mobile phone clients, compatable with even the most basic phones, and the built-in mail client on most phones should work well with Gmail.
Scenario
I have an HTML/javascript website that uses javascriptSOAPClient communicate with an ASP.NET 1.1 web service in order to read/write to a SQL database. (http://www.codeproject.com/KB/ajax/JavaScriptSOAPClient.aspx). The database contains anonymous demographic information--no names, no credit cards, no addresses. Essentially the data collected is for data mining purposes.
The site is live, but we want to introduce a more secure communication between the javascript/ajax client and the wbe service for both this and future projects. Working as contractors in the financial industry, at some point we're going to get nailed with the question: is this website hackable? If we don't have a solution we could be out on our ears.
I am already following best practices such as communicating with the database via command parameters and stored procedures). However, currently anyone could browse to our web service description and figure out how to consume our exposed services.
Questions
With my hybrid solution (i.e. not end-to-end Microsoft) how should I go about authenticating client requests on the web service?
If I start passing a username/password or some other identifiable element into the web service as authentication, should I be concerned about how that key is generated/stored on the client side?
A few suggestions to consider:
List the threats, and compare each to your current setup.
Use SSL / HTTPS. This alleviates a whole class of vulnerabilities.
Use username/password, generated on the server side and sent out of band (in the post or by phone) to the user. (Hope this answers question 2).
Use 2-factor authentication. To do this, you can look at security tokens such as RSA's keyfob-type gizmos or look at Steve Gibson's Perfect Paper Passwords
The easiest solution from a programming standpoint is to use two way HTTPS. That is, the server presents a certificate to the client, and the client presents a certificate to the server. Then only clients with proper certs (issued by you) can connect.
That helps reassure clients that your site is not generally accessible, yet the security is transparent to the application and, once they've signed up and received a cert, to them. The downside is that you have admin overhead in issuing and tracking the user certs -- but that's probably less than you'd have dealing with username/password combos.
There are a few simple options:
SSL + Cookie
If the web app is also ASP.NET and hosted along with your web service, then you should have access to the User/Membership/Session of the web app inside your web service (essentially #1, but you get it without doing any work).
If the web app and web service are not on the same domain, then cookies are out due to cross-domain issues - so you can have the web app embed a GUID into a hidden form field, and use that GUID as a sort of cookie (and it will need to be passed as a parameter on all web service requests).
Can you incorporate a certificate authentication mechanism? So that only clients that have keys you can verify can communicate? That's how the product I work with has its managed devices communicate back to the core.