Well, I can pull the delivery failures out of the mailbox using the
\\.\backoffice <file:///\\.\backoffice>  file path, but it's not pretty.
Using it also means I have to find another solution soon because I'm in
the process of getting rid of those E2K3 servers.

 

It seems like the hard part is getting them out of the mailbox.

 

I'm considering sending them to a dead-end queue, and pulling them out
of there as .eml files using the EMS export-message cmdlet.

 

As far as getting them to the queue, I was thinking of either sending
them from (or just re-directing the returns to) a non-authoritative
domain, setting up a send connector for that namespace, and dead-end it
(maybe smarthost it to an unreachable address).  All the returns should
collect in that connector's queue, and then it's just a matter of using
the EMS cmdlets to export them, and keep the queue cleaned up.  

 

Thoughts?

 

________________________________

From: Michael B. Smith [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 11, 2008 7:56 PM
To: MS-Exchange Admin Issues
Subject: RE: How to programmitically capture delivery failures.

 

Actually, what you want is the M: drive.

 

I am one of the few that regret that that capability was removed from
Exchange 2007 (in Exchange 2003, it was available as
\\.\BackOfficeStorage\<primary-domain>)

 

Regards,

 

Michael B. Smith

MCSE/Exchange MVP

http://TheEssentialExchange.com

 

From: Campbell, Rob [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 11, 2008 8:54 PM
To: MS-Exchange Admin Issues
Subject: RE: How to programmitically capture delivery failures.

 

Forget that idea.  I was thinking a journal report was stored outside of
a mailbox.  I'm no better off trying to get that than the original
email.

 

Seems like this ought to be easier.  I wish exmerge had an option to
export to .txt.

 

________________________________

From: Campbell, Rob [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 11, 2008 7:48 PM
To: MS-Exchange Admin Issues
Subject: RE: How to programmitically capture delivery failures.

 

I was hoping you'd drop in.

 

I was just considering the possibility of setting up a mailbox to
receive the DSNs, journaling the mailbox and extracting the data out of
the journal reports.  

 

________________________________

From: Michael B. Smith [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 11, 2008 7:38 PM
To: MS-Exchange Admin Issues
Subject: RE: How to programmitically capture delivery failures.

 

I programmed this for a client using a PowerShell script based on the
DSNs they received. I don't own the code, so I can't post it, but I can
share that the Lumisoft NET library is a godsend for doing this kind-of
stuff. It doesn't make it "easy", because you've got to program around a
few bugs in their MIME implementation, but it makes it quite feasible
and not extraordinarily difficult.

 

And if you use the POP-3 interface or the IMAP interface, the Exchange
version doesn't matter (and you can use various 3rd party mail servers
as well).

 

Regards,

 

Michael B. Smith

MCSE/Exchange MVP

http://TheEssentialExchange.com

 

From: Campbell, Rob [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 11, 2008 7:39 PM
To: MS-Exchange Admin Issues
Subject: How to programmitically capture delivery failures.

 

Problem: 

An application has a user database with email addresses.  The
application will send an email to the users in the database
periodically.  The application developers want the emails addresses from
any of these that came back undeliverable captured and sent back to them
to clean up the database.

 

Environment - Exchange 2007 Edge and Hub Transport servers.  Exchange
2003 servers on the back end with the mailboxes. (No 2007 mailbox
servers yet).

 

We're using an outsourced mail host (Message Labs) for delivery, so the
protocol logs aren't much help.  All outbound email will initially be
accepted by the servers at Message Labs, so there won't be any delivery
failures reported in the protocol logs on the Edge servers. 

 

Any email returned to the sending address should be a DSN.  There
shouldn't be any replies or other inbound email to that address.  

 

If I can get the incoming DSN's routed to a text file, I can parse out
the information I need.  

 

Originally I was thinking about just letting them go to BADMAIL, but it
seems that Exchange 2007 doesn't give you that option.

 

Any ideas?

 

 


************************************************************************
************************** 
Note: 
The information contained in this message may be privileged and
confidential and 
protected from disclosure. If the reader of this message is not the
intended 
recipient, or an employee or agent responsible for delivering this
message to 
the intended recipient, you are hereby notified that any dissemination, 
distribution or copying of this communication is strictly prohibited. If
you 
have received this communication in error, please notify us immediately
by 
replying to the message and deleting it from your computer. 
************************************************************************
**************************

 


************************************************************************
************************** 
Note: 
The information contained in this message may be privileged and
confidential and 
protected from disclosure. If the reader of this message is not the
intended 
recipient, or an employee or agent responsible for delivering this
message to 
the intended recipient, you are hereby notified that any dissemination, 
distribution or copying of this communication is strictly prohibited. If
you 
have received this communication in error, please notify us immediately
by 
replying to the message and deleting it from your computer. 
************************************************************************
**************************

 

 

 


**************************************************************************************************
 
Note: 
The information contained in this message may be privileged and confidential 
and 
protected from disclosure.  If the reader of this message is not the intended  
recipient, or an employee or agent responsible for delivering this message to  
the intended recipient, you are hereby notified that any dissemination,   
distribution or copying of this communication is strictly prohibited. If you  
have received this communication in error, please notify us immediately by  
replying to the message and deleting it from your computer. 
**************************************************************************************************
~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~
~             http://www.sunbeltsoftware.com/Ninja                ~

Reply via email to