Forward to another MTA after backoff time

Hi,

> What will happen if the message delivery still fails

> after the backoff time?

The backoff keyword specifies retry times. If for example you have:

backoff "pt5m" "pt10m" "pt30m" "pt1h" "pt2h" "pt4h"

A failed message will try again for delivery after 5 minutes/10 minutes/30 minutes/1 hour/2 hours/4 hours and every 4 hours after this.

The message will only 'bounce' back to the sender once the notices period has expired (specified by the notices keyword).

> Can I forward the message to

> another MTA on the same network? How do I configure?

What is the problem you are trying to overcome? Why would another MTA on the same network be able to get through to the destination system but the MTA the email is currently on not get through?

Regards,

Shane.

shane_hjortha at 2007-7-12 8:22:26 >

Hi,

This same issue has already been discussed on this forum:

http://forum.java.sun.com/thread.jspa?threadID=5160118&tstart=45

You are attempting to solve an underlying network issue by 'hacking' the messaging server MTA - which is completely the wrong approach.

Regards,

Shane.

shane_hjortha at 2007-7-12 8:22:26 >

Hi,

> I have read through the post that you are pointing. I

> am interested in the hackish solution. Here is what I

> understand from the solution.

>

> 1) cron job ping remote host at fixed interval

> 2) if no response, stop the MTA dispatcher

> 3) MTA will try to find another MTA on the network

> and forward the message to it

> 4) when there is a ping response, start MTA

> dispatcher

This doesn't resolve the problem of messages that are already 'stuck' in the MTA which has the 'broken' outgoing leased line. This only works-around any *new* emails becoming stuck.

> Here are my questions:

>

> 1) Which remote host do I ping? Normally we will ping

> the ISP's DNS server. The result often does not

> reveal network connectivity problem. There are a lot

> of times we can ping any host but firewall or proxy

> down the routes (outside LAN) block the traffic. How

> do I cater for such situations? Can I use telnet?

You ping any reliable system on the other end of the leased line. When the pings don't return then either the host is dead or the leased line is down. Hopefully it is the latter.

> 2) How does the MTA finds another MTA on the same

> network? Does it do this automatically or I have to

> configure?

MX records. This is explained in the thread.

But as I already noted.. this is a _network_ issue best solved using network level methods e.g. BGP routing.

Regards,

Shane.

shane_hjortha at 2007-7-12 8:22:26 >

Hi,

> Can I customize the MTA so that after notice time,

> the email is redirected to a custom channel (instead

> of rebounce to the sender) which is pointed to the

> other MTA on the same network?

There isn't a keyword to do what you suggest.

The 'hackish' way would be to add 'daemon <mta2>' to the channel which has the stuck emails, then rebuild the config; restart the MTA so that emails in say tcp_local are handed off to <mta2>.

Regards,

Shane.

shane_hjortha at 2007-7-12 8:22:26 >

Hi,

> I do not fully understand the behavior of daemon

> channel keyword.

Emails enqueued in the channel which has the daemon <hostname> will be sent to <hostname> only. In sendmail parlance, this is the 'smarthost'.

> I think by adding the keyword, all mails coming into

> MTA1 will go straightaway to MTA2 before going out

> (in the case of tcp_local). No mails will go out from

> MTA1. Is that correct?

Correct. You would only do this when MTA1 is unable to send emails out directly (when leased line is down). For example an email for @gmail.com will go via tcp_local, tcp_local by default will do an MX lookup and try to send to mx1.gmail.com directly. Adding the daemon <MTA2> will cause the emails to be sent to MTA2, and if MTA2 has a valid connection it will send the emails onto mx1.gmail.com.

Once the leased line is back up, you could remove the daemon <MTA2> and emails would go direct again.

> The purpose of having two MTAs in the first place is

> to load balance them. If that is what will happen, it

> kind of defeats the purpose. :o)

This may have been the original goal, but who-ever set it up didn't think it through very well. I suggest you spend some money and get the appropriate router in place and not rely on the MTA doing something it was never designed for.

Regards,

Shane.

shane_hjortha at 2007-7-12 8:22:26 >

Hi,

>> While the MTA is retrying, is the message held in the queue of the channel or a special >> channel?

Messages are held in a queue. The immediate difference between an email that has yet to be attempted to be delivered and one that has failed to be delivered the first time and is being retried is that the filename of the first delivery-attempt will start with ZZ and the first re-attempt will start with ZY, then ZX for the second re-attempt and so on.

>> Is the message mark with .HELD?

A .HELD message is 'invisible' to the job-controller so will never be delivered unless it is manually changed back to an 'active' message (e.g. if the message file is renamed or the message is 'released').

Regards,

Shane.

shane_hjortha at 2007-7-12 8:22:26 >