Blog Entry

I started a series of "How does Novell do it" posts and I asked for suggestions on future topics. I am still looking for some of those by the way. What I have so far is this:

1. How to force the DSN system to fire.
2. How to force the DEFER system to fire.
3. How to make the gwia do it's things on demand, while you watch the log screen in either verbose or diagnostic mode.
4. How about a guide to some of the more saliant points when the log is set to diagnostic mode.
5. How to make the POA show its rule processing logic when logging is set to diagnostic.

And a discussion on the best practices guide.

I am going to conveniently ignore the best practices for now, but I will cover some of that in a later post. So, I'll start at the top of the list and cover the first two here:

How to force the DSN system to fire.

That description is a little ambiguous so I'm not really sure how to answer it.  For those that don't know DSN is Delivery Status Notification and it allows some message tracking across the Internet.  It has to be enabled on the GWIA (ESMTP Settings | Enable DSN) and requested by the client (Tools | Options | Send | Mail | Internet Mail).

What happens, when enabled, is that the MAIL FROM and RCPT TO commands of the SMTP header are modifed and look like this:

MAIL FROM: SIZE=491 RET=HDRS ENVID=groupwise.44EDBBC0.34D:8b:34d0:N
250 2.0.0 jsimpleton@nodomain.com OK
RCPT TO: NOTIFY=SUCCESS,FAILURE ORCPT=smtp;groupwise-bogususer@novell.com:1:1
250 2.0.0 bogususer@novell.com OK

The RET, ENVID, NOTIFY and ORCPT commands are all DSN related commands that tell the mailer-daemons how to handle the status tracking.

Now the question on how to make it fire?  Well, you can't.  It's status tracking and it's handled automatically.  Just like you can't make GW internal status tracking 'fire'.

How to force the Defer system to fire 

A little ambiguous too, but it does have an answer.   You can force a mail to be deferred by sending to a mailer daemon that you know is down.  How I do this is I maintain my own DNS server, on NetWare for my test systems.  I create A and MX records for each server that I have (physical or VMWare) so that all my servers can happily mail between themselves and TO the outside world.  Replies FROM the outside world don't work of course, because I am making up my own domain names.  So, if I just stop a GWIA on one of my servers and send a mail to that system from another system the message gets deferred.

You can probably achieve the same by creating a ROUTE.CFG in the GWIA directory and redirecting mails to a particular domain to an IP address that you know doesn't have a listener on port 25.

That answers the question on how to force mails to be help up in DEFER, but how do you force mails in DEFER to get processed again?

Restart the GWIA is the quick answer - on startup the GWIA will process it's defer queue.  The long, drawn out,  answer is that you can force more defer retries.  On the GWIA object there is an 'Interval to retry a deferred message' setting. This is a free form field that you can enter as many intervals as you like.  I am now getting Deja-vu - did I blog this bit before?

Anyway in that setting you can specify how often and how long between intervals.  So, '1,1,1,1,1,1,10,20,60' would retry the message every minute for 6 iterations, then again after 10 minutes, 20 minutes and 60 minutes.  It would then retry every 60 minutes until the Maximum Defer age was reached (default of 4 days, or 96 hours - also configurable).  If you wanted to, and were a little mad, you could just let it retry every minute by just putting '1' in that field.  I would not recommend that though as it will create a huge load on your GWIA.

I think that covers it - anyone got questions or more suggestions for topic?