On Tue, 26 Oct 1999, Philip Hazel wrote:
> On Mon, 25 Oct 1999, Hugh Sasse wrote:
>
> > > "Cannot route" means "took the address, ran it through the directors
> > > and/or routers as configured, and none of them could handle it". There
> >
> > Could the reason why it could not be handled be added in, then, as one
> > gets good diags for a normal delivery failure or defer?
>
> The problem is that it's "reasonS", not "reason". You may have a lot of
> directors. Even with the default set, the full information might look
> like
>
> system_aliases failed to handle address - no match in /xxx/yyy
> userforward failed to handle address - no such user
> localuser failed to handle address - no such user
I think that knowing that last one tried and its reason for failure would
be a big help. The progression through directors is well-defined (even if
it took me a while to click! :-)), so reaching localuser implies
progression though system_aliases, etc.
>
> and if you were handling virtual domains and mailing lists as well it
Certainly when one address gets expanded to many, it is more difficult.
> could become a very long piece of text. Similarly for remote addresses
> in cases when you have a number of different routers.
Again, the progression is well defined. If the last driver should never
have been reached, that itself is some diagnostic clue. OK, there are
diminishing returns here, and the line must be drawn somewhere. People may
ask for information on why the last driver was reached, etc, but I think
the reason why it finally gave up is at least a useful point to draw the
line.
> > If this
> > would make the message too long, could you consider just adding an
> > error number, when you revisit that RFC about error code returns (raised
> > in the context of internationalisation earlier)? Well, if you decide
> > to persue the concept of error numbers, anyway. :-)
>
> I rather doubt that there are error codes which match all the different
> circumstances.
>
I'll concede that one, certainly -- 24 bit error codes would
be a bit much!
>
> --
> Philip Hazel University of Cambridge Computing Service,
> ph10@??? Cambridge, England. Phone: +44 1223 334714.
> Government Policy: If it ain't broke, fix it till it is.
>
>
Thank you,
Hugh
