I recently wrote an application for our company to process newsletter signup requests via signup emails sent to an inbox on our Exchange 2003 servers using WebDAV. This all works fine.
Now we've realized that for auditing purposes, we need to capture the ip address of where the signup request originated. My question is, is there a way to request the original ip address of the originator of the email with my WebDAV request?
I've browsed through the urn:schemas:mailheader: and the urn:schemas:httpmail: documentation and didn't see a field you can request with this data besides maybe urn:schemas:mailheader:path. But when I make a request to our exchange server with the path in the request, the status for that property comes back 404 not found.
It looks like http://schemas.microsoft.com/cdo/smtpenvelope has a clientipaddress property that would have this information, but that is only applicable to messages still in transit.
Has anyone had to do this before and figured out a way to snag the ip address of the user who originated the email? It probably isn't helpful to the question, but the format of my WebDAV request is below:
string webdav =
#"
<?xml version=""1.0""?>
<D:searchrequest xmlns:D = ""DAV:"">
<D:sql>
SELECT
""DAV:displayname"",
""urn:schemas:httpmail:fromemail"",
""urn:schemas:mailheader:subject"",
""urn:schemas:httpmail:textdescription"",
""urn:schemas:mailheader:date""
FROM
SCOPE('shallow traversal of ""{0}""')
WHERE
""DAV:isfolder"" = false AND
""urn:schemas:httpmail:read"" = false
</D:sql>
</D:searchrequest>
";
This comes back to SMTP more than it comes to Exchange/WebDAV. It really depends on which email service the end user is using. SMTP can pass an email around multiple times before it ends up at the destination. Normally, each hop adds a Received: from header, with some additional information like an IP address.
But, some services, like Google, don't count the user sending the email has a hop, and the originating IP address is a Google SMTP server. So you'll never know the end user IP address from the email. Then, other services may count the end user's public IP address as the first hop. And some other services may add a special header like X-Sender-IP or X-Originating-IP to the message.
So, there isn't a guaranteed way to obtain that information. Part of it has to do with the distributed nature of SMTP, the prevalence of webmail and some privacy concerns. If this information is critical to your auditing, you may want to setup a simple webform which could send an email to this inbox, and then you could add additional information like an IP address to the body of the email.
Related
I am trying to send an email using c# MailMessage to a hotmail account but the emails are always going to junk.
How can i send emails directly to hotmail inbox in c#?
I don't have my own smtp server, therefore i have tried using my university smtp and other smtps like google, yahoo... but all emails were sent to junk.
Any solutions?
This is not really a C# question.
Mails are sent to spam depending on their content and their headers so you should check a few things :
You need to have a subject
you shouldn't have spammy words (sex, viagra, love, watches)
You need to have a return-to and a from address headers that match
You need to be consistent with your encoding, if you go for UTF8 send UTF8 text
You shouldn't insert images
Your links inside the mail, if any, should have their text set to the address they are going to
Using these strategies should help your email not being classified as spam.
You can always check the headers of one of the mail that went into spam. It is often described what rules were applied and where the mail failed.
In hotmail, open the Junk folder, click on the message. Hotmail will display options in the body of the message - click on "Wait, it's safe!" Hotmail will move the message to your inbox, and mark the FROM email address as safe.
There is (probably) nothing wrong with your code - it is hotmail identifying the sender and/or subject as being junk.
Although it may well be out of your control, junk email filters generally work on a weighting system, so there are things that you can do to make your email look less like spam.
To start with, check that:
your subject doesn't contain all caps or sensitive words (such as "FREE!")
your body has content
the 'from' address for the MailMessage exists.
If those are all fine, have a look through this list, this article on live.com and the Policies, Practices and Guidelines for Hotmail.
What is the content of your mail, is it text that is likely to be regarded as junk mail by spam filters? Have you tried sending to other accounts such as Yahoo or Gmail?
You can't do it from C#.
It is up to the recipient to route the messages to junk or inbox or wherever it decides to put the message. If the sender were allowed to decide where the message went on the client's side, imagine how much bigger of a problem spam would be.
One solution you can employ is to have your target mail account 'whitelist' the sender, but that may not be an option in all cases.
We have written an Outlook add-in in C#, that appends a custom header to outgoing messages.
This add-in has to use a library called Redemption to bypass Outlook's security to modify the headers, and this is all working great.
Our problem lies when sending outgoing mail through an exchange server. We use the additional header as such:
Add a References header with an email address that includes an ID for tracking with our system.
This is a standard email header that all mail clients should pass on when replying to messages. So replying to a message will automatically keep the new message tracked.
All of this works just fine if you send an email from an IMAP account setup in Outlook such as GMail.
Problem is, if you send mail via an Exchange account, the Exchange server overwrites the References header and uses it's own proprietary headers: Thread-Index and Thread-Topic. Email standards suggest to use References and In-Reply-To headers. See this link on this issue.
Does anyone know a way around this? Some algorithm to gain us the following:
Add a header (of any name or kind) to emails that includes a 10-digit ID and 3 letter prefix
Replying to this email from all (or most) mail clients preserves the custom header
I think the following algorithm is going to solve our issue:
Our Outlook add-in will set the References and an arbitrary X- header
Our mail filter will look for References, if found use it (if outgoing mail server was Exchange, it will not be present)
If our mail filter finds the arbitrary X- header and a Thread-Index, it will store the data found in the X- header.
Later if the email is replied-to several times, the mail filter will use the Thread-Index to look up the past info to keep the email tracked.
For those wanting to know internals of the Thread-Index header, it is a Base64 encoded string. The first 22 bytes are the original unique portion and each reply adds an additional 5 bytes on to it. We only use the first 22 bytes to identify the email.
I have a service that is running in Amazon Ec2. The service exposes both a http endpoint and a https endpoint. I am doing some geo lookup on the user IP address when I log the data. Everything works just fine on requests coming into the http endpoint. I have to grab the X-Forwarded-For header so that I do not take the Amazon Load Balancer UP Address and I am always able to get what I need. However on requests that come in on the https endpoint all of the IP addresses are the same.
In order to pull the IP address I am using the following C# code:
public static string FetchClientIp(HttpRequest req)
{
var value = req.Headers["X-Forwarded-For"];
return string.IsNullOrEmpty(value) ? req.UserHostAddress : value;
}
I can't find anything else that I need to do that is specific to https requests so I'm hoping someone here has run into this before. I'm going to spin up a test on this to try to better isolate the problem.
Thanks
It depends how you have your ELB set up.
If you're terminating SSL on the ELB (new feature as of October 2010), then the client IP address will be in "X-Forwarded-For".
HttpContext.Current.Request.Headers["X-Forwarded-For"]
It sounds like you're terminating SSL on your web servers, then ELB can't decrypt the traffic and add the "X-Forwarded-For" header to the HTTP request. So the client IP address in the header "REMOTE_ADDR" (which is the header returned by HttpRequest.UserHostAddress) is the IP of the last hop -- in this case the internal IP address of the ELB.
Keep in mind, "X-Forwared-For" may contain multiple IP addresses as described at http://docs.amazonwebservices.com/ElasticLoadBalancing/latest/DeveloperGuide/index.html?SvcIntro.html#X-Forwarded-For. In that case, you're probably most interested in the first address listed.
I like to check the validation of an email address with ajax by onblur? (asp.net,c# and...json or anyother I don't know)
I thought it could be possible with json and calling a webservice. but are there any (free)services to call? or I have to write my own? Hope you understand me what I want.
Thanks
If you just want to validate the format of an email address, you can do it using regular expressions in javascript without having to do any ajax calls. Check out this related thread
If instead, you want to check whether an email address is real, I'm afraid it isn't possible. There isn't a database of all existing email addresses.
The whole notion of whether an e-mail address "exists" is somewhat ambiguous. Does an auto-responder address "exist"? Does an address which can receive mail that is immediately discarded "exist"? Some mail servers can be effectively probed by initiating a mail delivery session and seeing if the mail server rejects the address as illegitimate. More savvy mail servers may quietly accept and discarded mail destined for "bogus" addresses to prevent address validation (i.e. to keep spammers from getting "good" addresses). What you're asking is non-trivial, and there's not really a clear cut answer.
There's no real way to confirm an email really exist other than sending it an email and seeing if you get a bounce-back (And even then some domains have catch-all's configured so it may not actually be an email).
You can validate the format of it to make sure it looks vaguely like an email. To truly validate an email takes an ungodly complex regex (I've yet to see one that truly encompasses the scope), but a simple check that'll rule out most keyboard-mashing is pretty easy. I typically use:
^[A-Za-z0-9._%+-]+#[A-Za-z0-9.-]+\.[A-Za-z]{2,6}$
There's a lot of fake emails it will accept, but it does a reasonable job of forcing the user to enter something legitimate. Be wary if using a more complex regex that you don't accidentally ban any legitimate addresses, the email spec is very broad in what's allowed.
You could also try doing a DNS lookup on the host portion of the email (After the #) for an extra level of protection, but I'm not sure how much you'll get from this as you'll just force them to lie with a real domain name.
Our group (corporate environment) needs to monitor a couple of faceless accounts' Outlook inbox for specific types of bounced e-mails.
WebDAV (using C# 2.0) is one of the paths we've traveled and we're almost there, except for one minor problem: we're getting the response below for the e-mail body element
<a:propstat>
<a:status>HTTP/1.1 404 Resource Not Found</a:status>
- <a:prop>
<a:htmldescription />
<a:textdescription />
</a:prop>
</a:propstat>
The only real commonality is that it only happens on messages that our Exchange server is returning to us as "Undeliverable". Note: All other e-mails come across just fine.
Any thoughts?
It looks like undeliverable messages in Exchange have a content-type of "multipart/report; report-type=delivery-status". Probably because they don't have a body, just a summary of the delivery attempt which can actually all be gathered from the Headers of the message. Perhaps the WebDAV access (I don't have access to an OWA account right now to check) doesn't know what to do with that, i.e. is just thinks the e-mails don't have a body.