Storing emails elsewhere when Exchange server goes down

Question

I'm using a DataGrid and would like to introduce a style trigger for cells that sets the background color of the cell depending on the column's IsReadOnly property. I think there is some way to get from the cell level to the column level using RelativeSource (navigating all the way up to grid and from there back down to the column), but I cannot figure out the exact path to use.

Solution 1

You could setup any number of failover mechanisms but in all reality, 99% of all email servers will simply queue the email (usually for a maximum of 48 hours) and continue to retry sending the email until your server is available again.

Solution 2

Actually I just experienced twice an instance where when the server goes down the mail was not held and delivered. The situation is using exchange 2003, the internet went down, the router used between the exchange server and the internet was UPNP, the wizard was used to set it up. After the internet was brought back online, less than 12 hrs from the time it went down, the exchange server still could not reach the internet, the user had to run the IECW over again on the server to get things working, none of the emails during the downtime ever reappeared.
This seemed to be an isolated incident until it happened again a month later. Same scenario, same server, same router. Not sure if the router is at fault or the server, but have since manually configured the router to hopefully prevent this from happening in the futures. So a backup solution might not be such a bad thing after all.

Solution 3

RFC 5321 explains in detail how sending and receiving emails works.

Two important things in it I'll mention here

1. Mail that can't be delivered for whatever (temporary) reason MUST be queued and retried at a later time. Here the citation

   Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days. It MAY be appropriate to set a shorter maximum number of retries for non- delivery notifications and equivalent error messages than for standard messages. The parameters to the retry algorithm MUST be configurable.

2. Mail that can't be delivered at all MUST be indicated to the sender. Here the citation:

   If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse- path).

So if all mail servers act accordingly to the standard there will be no mail loss at all. But it is said that there are some few mail servers that don't follow the rules. In this case it shouldn't be your responsibility to accept their mails in all cases only because they have crappy servers.

I would recommend to have a "cold-standby" mail server which you boot up only in case of a long Exchange down-time.

Comments

[Admin]

Thanks for your help guys, I will try it in a virtual machine. Basically turning the server off and seeing if emails are still sent to it after a max of about 2 days.

[Ben]

Maybe try {Binding (DataGridTemplateColumn.IsReadOnly),RelativeSource={Relative‌​Source FindAncestor, AncestorType={x:Type DataGridTemplateColumn}}} ? Not quite sure since I don´t know your XAML structure. Maybe better post what you´ve got so far?

[Admin]

OK so are secondary/backup MX services not really worth it then?

[SLY]

I would take a look at mimecast, messagelabs, or postini.

[Admin]

What about Dyn's MX backup - dyn.com/email/dyn-email-backup-mx

[TPouliquen]

Using third parties for MX backup can be problematic, as differences in configuration between your and their servers could result in a backdoor for spam (e.g., if they accepting everything, and you accept everything from them), bouncing of messages that should have been accepted, or not bouncing messages at all. For Dyn in particular, you probably ought to read Things Not To Do with Dyn Email Backup MX to see if any of those are incompatible with how you operate your primary.

[Espen Schulstad]

I see, the only real reason the server would go down is really internet or power problems, which are usually fixed in the same day anyway.

[mailq]

This is why SMTP was designed so failsafe. It was invented at a time where computers were EXPENSIVE and rare, and where you hadn't Internet connection and power all the time. Only nowadays everybody expects a 24/7-no-downtime service.