> The problem is that a fast email delivery is essential for us and
> our customers.
In that case, I would recommend explaining the situation to your customers.
> Fast communication is very important in business, why should a mail
> server wait to deliver mails (maybe for hours), if there is a easy
> way to do it fast.
Ah, but it isn't that easy. We've already gone over what the RFCs say (the remote
mail server is *telling* IMail to keep trying at that server). But, how does IMail
know which will be faster? Normally, if there is a problem with a primary mail
server, the backup will accept mail... but only deliver it once the problems with the
primary mail server are fixed.
> Is it the best way to wait until a primary mail server is up again or
> isn�t it much better to try a secondary server if available and
> deliver the mail asap?
There are two problems with this: [1] The primary mail server is requesting that you
do NOT go to the backup, and [2] There is no way to know that the backup will indeed
deliver the mail faster than you can by connecting to the primary.
Imagine the people who are set up with backup mail servers that do not accept mail for
them (*lots* of mail servers are set up like this). If IMail is changed in the way
you want, then when you send mail to one of these servers, you will get a "bounce"
message back saying the user doesn't exist. So by trying to fix someone else's
problem, you end up with another problem.
Of course, it *would* be nice if IMail had a feature making this as a configurable
option, so people could choose how they want to handle the situation.
--
-Scott
Declude: Anti-virus and Anti-spam solutions for IMail. http://www.declude.com
--
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
