PeopleSoft Adoption Made Smooth & Simple!
On-The-Job Training Is made Intuitive & Easy With WalkMe's On-Screen Guidance Tool. Claim Your Free WalkMe Account Now
Course Of The Month
7 days, 12 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Proof of delivery
Posted on 2012-12-27
Hello all,
Someone says they sent us an e-mail months ago to one of our "main Mailboxes" that we did not see or find in our exchange server. We have e-mails from that "mailbox" that go back a couple of years in ".PST" files that were moved from the server to save on space. We did not find that e-mail in the PST files either. They provided a "log" from their"email content gateway" (Mail Marshal) that supposedly confirms that it was delivered to our server. Our server was a Windows 2003 server with exchange 2003 that we just migrated (about a month ago) to a Windows 2008 R2 server with exchange 2010.
My questions are :
How can I officially confirm (and have proof) that the e-mail did not reach our servers? Does exchange 2003 have a feature I can use to see if it did reach the server and would I be able to use it now in the new server since it was migrated?
How reliable is this "Log" they provided and is it real proof?
What software (or service in exchange 2010) can I use to keep these type of records in the future to give actual proof that e-mails Did/didn't get delivered?
We have not decommissioned the old 2003 server yet so I would be able to get to it if needed.
Thank you in advance for your help! It's much appreciated!
Someone says they sent us an e-mail months ago to one of our "main Mailboxes" that we did not see or find in our exchange server. We have e-mails from that "mailbox" that go back a couple of years in ".PST" files that were moved from the server to save on space. We did not find that e-mail in the PST files either. They provided a "log" from their"email content gateway" (Mail Marshal) that supposedly confirms that it was delivered to our server. Our server was a Windows 2003 server with exchange 2003 that we just migrated (about a month ago) to a Windows 2008 R2 server with exchange 2010.
My questions are :
How can I officially confirm (and have proof) that the e-mail did not reach our servers? Does exchange 2003 have a feature I can use to see if it did reach the server and would I be able to use it now in the new server since it was migrated?
How reliable is this "Log" they provided and is it real proof?
What software (or service in exchange 2010) can I use to keep these type of records in the future to give actual proof that e-mails Did/didn't get delivered?
We have not decommissioned the old 2003 server yet so I would be able to get to it if needed.
Thank you in advance for your help! It's much appreciated!
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
5 Comments
Active 2 days ago
Message Tracking will tell you if the email was processed by Exchange. However it is not enabled by default on Exchange 2003, and in most cases only keeps the log for a certain number of days. Message Tracking is enabled by default on Exchange 2010, but again only keeps the logs for a certain number of days.
Without seeing the log, it is hard to say what it proves or not. Furthermore, logs can be easily faked, they are in a standard format and it only takes a bit of copy and paste to change the dates and you have "proof".
Proving a negative with email is pretty difficult, because unless the email passes through your server nothing is logged. How can you prove nothing is there (and you haven't deleted the "proof").
Simon.
Without seeing the log, it is hard to say what it proves or not. Furthermore, logs can be easily faked, they are in a standard format and it only takes a bit of copy and paste to change the dates and you have "proof".
Proving a negative with email is pretty difficult, because unless the email passes through your server nothing is logged. How can you prove nothing is there (and you haven't deleted the "proof").
Simon.
Active today
Proof of sending is not proof of receipt.
There is no 100% sure method or proof that the email was actually sent:
- the route to the intended recipient was down,
- an incorrect email address was used by accident and returns back bounced
- a mailserver break out off the internet, dns conflict/errors/down,
- the internet pipe to the destination country is down
- your email address is marked as junk/spam
the list goes on....but you can search your mail server assuming the msg tracking is on
http://exchangeserverpro.com/exchange-2010-message-tracking-log-search-powershell
http://exchangeserverpro.com/searching-message-tracking-logs-by-sender-or-recipient-email-address
there is also queue (in exchange) which is a temporary location where messages that are waiting for processing are stored. In Exchange 2003 and earlier the queues were stored on the local disk in the c:\mailroot\queue directory, or a queue directory in the Exchange Server directory. Exchange Server 2007 and Exchange Server 2010 store their queues in an ESE database. This database is located in the “C:\Program Files\Microsoft\Exchange Server\TransportRoles\data
http://www.msexchange.org/articles_tutorials/exchange-server-2010/planning-architecture/smtp-routing-exchange-2010-part1.html
but really do not see reliability with claims unless third party comes in ..sort of like why we need a CA for PKI infra
There is no 100% sure method or proof that the email was actually sent:
- the route to the intended recipient was down,
- an incorrect email address was used by accident and returns back bounced
- a mailserver break out off the internet, dns conflict/errors/down,
- the internet pipe to the destination country is down
- your email address is marked as junk/spam
the list goes on....but you can search your mail server assuming the msg tracking is on
http://exchangeserverpro.com/exchange-2010-message-tracking-log-search-powershell
http://exchangeserverpro.com/searching-message-tracking-logs-by-sender-or-recipient-email-address
there is also queue (in exchange) which is a temporary location where messages that are waiting for processing are stored. In Exchange 2003 and earlier the queues were stored on the local disk in the c:\mailroot\queue directory, or a queue directory in the Exchange Server directory. Exchange Server 2007 and Exchange Server 2010 store their queues in an ESE database. This database is located in the “C:\Program Files\Microsoft\Exchange Server\TransportRoles\data
http://www.msexchange.org/articles_tutorials/exchange-server-2010/planning-architecture/smtp-routing-exchange-2010-part1.html
but really do not see reliability with claims unless third party comes in ..sort of like why we need a CA for PKI infra
Featured Post
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
When it comes to protecting Oracle Database servers and systems, there are a ton of myths out there. Here are the most common.
- Databases
- Oracle Database
- Acronis
- MongoDB
- Oracle
- *Backup Software
This post contains step-by-step instructions for setting up alerting in Percona Monitoring and Management (PMM) using Grafana.
- Software-Other
- Databases
- MySQL Server
- MongoDB
- NoSQL Databases
- Percona, *Monitoring tool
To show how to create a transport rule in Exchange 2013. We show this process by using the Exchange Admin Center.
Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center.
Navigate to the Mail Flow >> Rules tab.: To cr…
This is a high-level webinar that covers the history of enterprise open source database use. It addresses both the advantages companies see in using open source database technologies, as well as the fears and reservations they might have.
In this…
Suggested Courses
Course of the Month7 days, 12 hours left to enroll
728 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.